Netpulse_SasS/server/migrations/0037_config_retention.sql

-- =====================================================================
-- NetPulse :: 0037_config_retention.sql
-- Очистка старих версій конфігів: політика й окреме право на ручне
-- видалення.
--
-- Навіщо взагалі. Сховище версій росте вічно й нерівномірно: ZTE C320
-- віддає 32 854 рядки, це близько мегабайта на версію, і п'ять версій
-- одного хоста на стенді вже важать 4,7 МБ. Сотня таких хостів із
-- добовим розкладом — це десятки гігабайтів шифротексту в базі за рік,
-- зібраних заради питання, яке ставлять до останніх кількох версій.
--
-- Чому одиниць політики дві, а не одна.
--
-- Сама лише кількість («тримати 20 версій») втрачає історію там, де
-- конфіг чіпають щодня: двадцять версій — це три тижні, а розбір аварії
-- нерідко впирається в «а як воно було до літа». Сам лише вік
-- («тримати 90 днів») втрачає історію там, де хост не чіпали рік: усі
-- його версії старші за будь-який поріг, і чистка забрала б геть усе.
--
-- Тому обидві, і саме об'єднанням, а не перетином: версія лишається,
-- якщо вона входить у останні N АБО молодша за M днів. Кожна з двох
-- умов рятує рівно той випадок, у якому друга помиляється.
--
-- Розмір як одиниця свідомо не заводиться. «Скільки мегабайтів історії
-- конфігів вам треба» — питання, на яке ніхто не має відповіді, а
-- «як далеко назад я маю могти подивитись» — має. Розмір тут наслідок,
-- і його місце — у показнику поруч із політикою, а не в самій політиці.
--
-- Політика глобальна, без перевизначення на хост. Перевизначення
-- РУЙНІВНОЇ дії на рівні хоста — це спосіб втратити архів там, де
-- людина забула, що колись поставила на цей хост «тримати 5 версій».
-- Глибина архіву — рішення організації («ми маємо бачити півроку»), а
-- не властивість конкретного комутатора.
-- =====================================================================

-- ---------------------------------------------------------------------
-- Політика
-- ---------------------------------------------------------------------

ALTER TABLE ncm.backup_defaults
  -- Вимкнена типово, і це головне рішення міграції: увімкнути чистку
  -- сама собою вона не має права. Інсталяція, яка вже рік збирає
  -- конфіги, після накату отримала б несподіване видалення історії —
  -- рівно тієї, заради якої це все й ставили.
  ADD COLUMN retention_enabled  boolean NOT NULL DEFAULT false,
  -- Скільки останніх версій тримати завжди, незалежно від віку.
  ADD COLUMN retention_versions int NOT NULL DEFAULT 20
      CHECK (retention_versions BETWEEN 1 AND 10000),
  -- Скільки днів тримати завжди, незалежно від кількості.
  ADD COLUMN retention_days     int NOT NULL DEFAULT 180
      CHECK (retention_days BETWEEN 1 AND 36500),
  -- Коли прибиральник востаннє проходив по цьому тенанту. Не лічильник
  -- заради лічильника: без нього форма не може відповісти на «а воно
  -- взагалі працює», і людина дізнається про мовчазний збій прибирання
  -- тоді ж, коли й про переповнений диск.
  ADD COLUMN retention_last_run_at timestamptz,
  ADD COLUMN retention_last_deleted int NOT NULL DEFAULT 0;

COMMENT ON COLUMN ncm.backup_defaults.retention_versions IS
  'Тримати останні N версій кожного хоста незалежно від віку';
COMMENT ON COLUMN ncm.backup_defaults.retention_days IS
  'Тримати все, молодше за M днів, незалежно від кількості';

-- Колонка з першої міграції NCM, у яку ніколи ніхто не писав і ніхто не
-- читав. Лишається на місці (її могли б читати чужі звіти), але явно
-- позначена як недіюча — щоб наступний, хто шукатиме, де налаштована
-- чистка, не знайшов дві конкурентні ручки й не вирішив, що діє ця.
COMMENT ON COLUMN ncm.device_policies.retention_versions IS
  'НЕ ДІЄ. Політика очистки глобальна: ncm.backup_defaults.retention_*';

-- ---------------------------------------------------------------------
-- Право на ручне видалення
-- ---------------------------------------------------------------------

-- Окреме право, і навмисно не ncm:write.
--
-- ncm:write означає «може міняти розклад бекапів» — дія оборотна й
-- нічого не знищує. Видалення версії знищує єдиний слід того, як
-- виглядало залізо в конкретний день. Архів конфігів — це те, чим
-- доводять, що зміну зробили не так; давати право стирати доказ разом
-- із правом правити розклад означало б роздати його всім інженерам
-- мовчки. Той самий висновок, що й у 0036 для ncm:exec.
INSERT INTO core.permissions (key, description) VALUES
  ('ncm:delete', 'Видалення збережених версій конфігів')
ON CONFLICT (key) DO NOTHING;

-- Лише власник і адмін. Інженер (a3) не отримує: він має ncm:write і
-- вже вміє все, що потрібно для щоденної роботи.
INSERT INTO core.role_permissions (role_id, permission_key) VALUES
  ('00000000-0000-0000-0000-0000000000a1', 'ncm:delete'),
  ('00000000-0000-0000-0000-0000000000a2', 'ncm:delete')
ON CONFLICT DO NOTHING;

-- ---------------------------------------------------------------------
-- Індекс під вибірку прибиральника
-- ---------------------------------------------------------------------

-- Прибиральник нумерує версії кожного (хост, тип) за спаданням часу.
-- Наявний ncm_configs_device_time_idx дає рівно цей порядок, тож нового
-- індексу не треба — тут лише нагадування, чому його тут немає.

COMMENT ON TABLE ncm.backup_defaults IS
  'Спільний розклад збору конфігів і політика очистки старих версій';