Перегляд переліку таблиць моделі даних реєстру у режимі читання для версії-кандидата

Загальний опис

Розробка регламенту реєстру передбачає розробку моделі даних реєстру. Адміністративний портал надає функціонал по перегляду переліку таблиць моделі даних реєстру та їх структури.

Опис проблеми

Адмін портал дозволяє перегляд переліку таблиць моделі даних тільки для мастер версії регламенту реєстру. Цей функціонал дозволяє отримати перелік таблиць регламенту, що розгорнутий на прод оточенні, але не дозволяє перегляд таблиць регламенту реєстру моделі даних версії-кандидату.

  • Під час розробки моделі даних регламенту реєстру необхідно оперувати переліком таблиць моделі даних, що описані в liquibase конфігурації версії-кандидату.

  • Під час редагування моделі даних розробниками реєстру шляхом внесення змін в gerrit, необхідно показувати актуальну інформацію зі списком таблиць моделі даних в адміністративному порталі.

  • Невизначений стан змін в моделі даних до моменту публікації регламенту реєстру

Актори

  • Розробник регламенту реєстру

Глосарій

  • rrm - registry-regulation-management backend service

  • DataModelSnapshot - файл для зберігання стану моделі даних регламенту реєстру

  • DataModelSnapshot files - набір файлів (файл per table), що показують стан моделі даних регламенту реєстру по кожній із таблиць

Функціональні сценарії

  • Перегляд поточного стану моделі даних регламенту реєстру (перелік таблиць), що розробляється (в рамках версії-кандидату)

  • Перегляд значення атрибута "суб’єктність" в переліку таблиць

  • Отримання результату перевірки можливості успішного розгортання моделі даних

Дизайн існуючого рішення

current design

  • Розгортання БД відбувається в 2 етапи:

    • OKD run-db-scripts job, що запускається під час розгортання Citus. Розгортає preconditions для розгортання моделі даних регламенту реєстру (actual detailed behaviour out of scope)

    • Jenkins pipeline розгортання регламенту реєстру, а саме <registry-name>-data-model job. Розгортає модель регламенту реєстру.

  • registry-regulations-management зчитує та зберігає структуру БД в файли DataModelSnapshot файл окремо для кожної таблиці. Процес створення файлів відбувається під час запуску registry-regulations-management сервісу один раз

  • Rest API через сервіси доступу до DataModelSnapshot зчитують перелік таблиць шляхом зчитування переліку файлів DataModelSnapshot table file.

Загальні принципи

  • Внесення змін в модель даних регламенту реєстру відбувається шляхом внесення змін у відповідні liquibase файли

  • Структура liquibase файлів регламенту реєстру на файловій системі (та в git) не змінюється

  • Кожна версія-кандидат використовує свою виділену БД для розгортування моделі даних

  • Використання еталонної БД для створення тимчасових БД для версій-кандидатів регламенту реєстру. Еталонна БД не містить даних реєстру

  • Підсистема розгортання регламенту реєстру (регламентний jenkins) створює структуру БД шляхом розгортання liquibase конфігурацій регламенту реєстру

  • registry-regulation-management зчитує стан розгортання регламенту реєстру (розгортання liquibase) з gerrit відповідного MR. Стан виконання відповідної jenkins job відображається в Gerrit MR по версії-кандидату за допомогою specific label (Verified +1)

Технічний дизайн рішення

target design

  • OKD run-db-script job створю еталонну БД під час створення та розгортання БД згідно з налаштування в citus repository. Еталонна БД повинна містити тільки структуру БД без будь-яких даних з реєстру.

  • Підсистема розгортання регламенту реєстру проводить розгортання регламенту реєстру для версій кандидатів після внесення будь-яких змін в відповідний Gerrit MR.

  • Підсистема розгортання регламенту реєстру створює тимчасові БД для кожної з версій-кандидатів, що знаходяться в роботі.

  • Підсистема розгортання регламенту реєстру розгортає модель даних регламенту реєстру шляхом використання liquibase конфігурацій з регламенту реєстру

  • rrm зчитує структуру даних з тимчасової БД та оперує DataModelSnapshot json схемою даних для комунікації (на рівні RestAPI)

  • Зчитування структури БД для мастер версії використовує registry БД. Тимчасові файли на файловій системі у форматі DataModelSnapshot не використовуються

Еталонна та тимчасова БД повинні бути створені тільки на DEV оточенні

Діаграми послідовності

Отримання переліку таблиць версії-кандидату
Figure 1. Отримання переліку таблиць версії-кандидату

Розширення підсистеми розгортання регламенту реєстру:

Необхідно розширити регламентний jenkins новим механізмом розгортання:

  • При створенні нового MR для версії-кандидату - створити та розгорнути тимчасову БД для відповідної версії-кандидату

  • При збереженні змін версії-кандидату (новий patchset в gerrit) - перестворити тимчасову БД для відповідної версії-кандидату і розгорнути liquibase changelog з відповідної мастер-версії, а потім з версії-кандидату

  • Процес розгортання моделі даних регламенту реєстру використовує механізм перевірки наявності змін пайплайну публікації регламенту реєстру (а саме get-changes кроку). Тимчасові БД розгортаються тільки при наявності нововнесених сзмін в моделі даних та при створенні версії-кандидату.

За вищенаведені дії відповідає єдиний jenkins codereview pipeline
Одночасно може виконуватись тільки один процес розгортання тимчасової БД в рамках однієї версії-кандидату

Опис роботи з тимчасовими БД

Логіка роботи:

  • Створити тимчасову БД для версії кандидату використовуючи еталонну БД.

CREATE DATABASE [registry-dev-<vcid>] WITH TEMPLATE registry-template OWNER [our owner user?];
registry-template - ім’я еталонної БД, отриманої після роботи OKD run-db-script-job. registry-dev-<vcid> - шаблон імені тимчасової БД для версії-кандидату.

  • Розгортання liquibase структури з відповідної версії регламенту реєстру (стан майстер версії, з якої було створено версію-кандидат, або на яку останній раз відбувалась rebase операція)

  • Розгортання поточної liquibase структури з версії-кандидату

Для доступу registry-regulation-management до тимчасових БД необхідно створити окремого користувача registry_dev_role. Користувач повинен мати права:

  • READ тимчасових БД

  • READ еталонної БД

Періодичний reconciliation процес

Reconciliation процес необхідний для видалення застарілих тимчасових БД по версіям-кандидатам (версії кандидати що були інтегровані в мастер версію або ті, що були видалені без інтеграції). Необхідно створити окремий jenkins pipeline для reconciliation процесу.

Логіка роботи reconciliation процесу

  • Отримати перелік версій-кандидатів в gerrit

  • Отримати перелік тимчасових БД для версій-кандидатів в БД

  • Видалити тимчасові БД версій-кандидатів для яких не існує відкритих MR в gerrit

Schedule налаштування

  • Виклик процесу reconciliation може обиратись індивідуально та налаштовуватись на рівні тригеру jenkins пайплайну.

Використання AbstractRoutingDatasource для доступу до тимчасових БД

Опис проблеми

Для доступу до тимчасових БД необхідно використовувати DataSource bean для кожної тимчасової БД. Існуючий код, що забезпечує роботу з БД мастер версії, використовує Spring bean типу DataSource. Для перевикористання механізму зчитування структури БД в DataModelSnapshot file пропонується використати AbstractRoutingDatasource механізм, що дозволяє створювати DataSource динамічно, в залежності від версії-кандидату, з якою наразі ведеться робота.

RestAPI

Поточний RestAPI розширюється можливістю отримувати перелік таблиць моделі даних регламенту реєстру. Структура запитів повторює відповідних запитів для мастер версії (`GET /versions/master/tables `)

Приклад запитів та відповідей на отримання переліку таблиць моделі даних версії-кандидату

Запит:

GET /versions/candidates/{versionCandidateId}/tables/

Структура відповіді:

[
    {"name":"Table 1","description":"Table 1 description","objectReference":true},
    {"name":"Table 2","description":"Table 2 description","objectReference":true},
    ...
    {"name":"Table n","description":"Table 2 description","objectReference":true},
]
Необхідно використати ті ж самі структури даних та коди помилок для запитів та відповідей, що використовуються для отримання переліку таблиць моделі даних в мастер версії

Розширення блоку відображення стану версії-кандидату інформацією про стан процесу розгортання тимчасових БД

Під час розгортання тимчасових БД проводиться також перевірка працездатності існуючої конфігурації liquibase changelog регламенту реєстру. При виниканні будь-яких проблем під час цього процесу необхідно передати цю інформацію в клієнтський додаток для відображення її розробнику реєстру.

Для отримання інформації про стан розгортання необхідно зчитувати Verified +1 label з відповідного MR в Gerrit

Необхідно розширити VersionInfoDetailed (Структура даних в RestAPI) інформацією про стан розгортання регламенту реєстру на тимчасове оточення шляхом додавання нового типу валідації в Validation bean.

Змінити ResultValues на:

  • UNKNOWN: процес розгортання та перевірки відбувається/не відбувався (відсутня Verified label)

  • SUCCESS: процес розгортання та перевірки успішний (Verified +1)

  • FAILED: процес розгортання та перевірки не успішний (Verified -1)

Додати в resultDetails інформацію (link) на відповідний gerrit MR (Optional)

TODO: пропрацювати UI дизайн

Розширення env cleanup процесу

Необхідно розширити існуючий механізм cleanup оточення шляхом додавання змін в delete-registry stage. Необхідно видалити всі тимчасові БД для версій-кандидатів. Зміни передбачають внесення відповідних інструкцій по видаленню тимчасових БД в CleanupRegistry.sql або створення окремого відповідного sql файлу з інструкціями. Видалення можливе по масці імені БД registry-dev-*. Також необхідно видалити еталонну БД з іменем registry-template.

Високорівневий план розробки

Необхідні експертизи

  • DevOps

  • BE

  • FE

  • QA/AQA

  • DBA

DBA

  • Розширити механізм розгортування БД в citus repository для створення еталонної БД

DevOps

  • Створити користувача в БД для registry-regulation-management сервісу. Permissions:

    • READ тимчасові БД

  • Розширити механізм cleanup env видаленням тимчасових БД та еталонної БД

  • Розширити підсистему розгортання регламенту реєстру механізмом розгортування liquibase конфігурацій регламенту реєстру в тимчасові БД

  • Додати reconciliation and cleanup механізм між переліком версій кандидатів та тимчасовими БД

  • Додати механізм публікації статусу розгортання тимчасової БД до відповідного MR в Gerrit

Backend

  • Створити механізм зчитування БД по заданому DataSource

  • Забезпечити створення DataSource spring bean для кожної версії-кандидату та майстер версії окремо

  • Розширити RestAPI для опрацювання запитів по моделі даних для версій-кандидатів

  • Видалити механізм використання файлової системи для зберігання DataModelSnapshot файлів для мастер версії Зчитування структури мастер версії повинно відбуватись кожного разу при обробці запиту на RestAPI рівні

  • Додати зчитування стану розгортання дата моделі в тимчасову БД в GET /versions/candidates/{versionCandidateId}

Frontend

  • Додати відображення стану розгортання тимчасової БД в блок з результатами перевірки версії-кандидату

  • Створити сторінку з переліком таблиць для версій-кандидатів