Всем привет!
23 июля Combodo выложили первую бету 3.3.0. Главное в ней я бы сформулировал так: это первое за много лет обновление модели данных CMDB. Combodo и сами это признают, в заметках по миграции прямым текстом написано, что после долгих лет стабильности модели данных в этой версии в неё внесено много изменений. Всё остальное вторично по сравнению с этим фактом.
Приятная новость в том, что CMDB перестали держать в замороженном состоянии. Неприятная в том, что за это придётся заплатить при обновлении, и про это отдельно ниже. Сразу оговорюсь: это бета, на прод её ставить рано, но развернуть тестовый стенд и посмотреть, что будет с вашей кастомизацией, самое время.
Что изменилось в CMDB
Отображение всех объектов CMDB привели к единому стандарту: две колонки (col:col1 / col:col2) и четыре-пять секций. В первой колонке «Общая информация» (имя, организация, статус, критичность для бизнеса, размещение, стойка, корзина) и секция специфичных для класса полей. Во второй колонке «Даты», «Электропитание» для устройств ЦОД и «Описание». Плюс на дашборд добавили классы, которых там раньше не было: Software, OS Family, OS Version, IOS Version, Tape, NAS file system, Fiber Channel Interface.
Группы. Класс Group в iTop был всегда, но был спрятан так, что им почти никто не пользовался. Теперь его вытащили в виде tagset-поля на каждом КЕ, и это сразу превращает группы в рабочий инструмент: пометить тестовый контур, зафиксировать периметр проекта, собрать список того, что идёт под обновление.
End of Support теперь задаётся на уровне Model и Software и показывается на всех связанных КЕ. Раньше эту информацию все растаскивали кто во что горазд, обычно в кастомное поле на самом КЕ.
Два новых опциональных модуля
Container Management добавляет класс Cloud в раздел виртуализации и четыре класса под контейнеры: ContainerImage, ContainerApplication, ContainerCluster, ContainerHost. Наконец-то из коробки, а не самописным расширением у каждого второго.
Data Flow Management мне показался интереснее. Появляется класс DataFlow, который описывает поток данных между двумя FunctionalCI: частота, тип потока, критичность. Сам DataFlow тоже является FunctionalCI, поэтому его можно привязать к тикету, и он участвует в анализе влияния. По умолчанию источник влияет на поток, а поток на приёмник не влияет. Кроме обычного анализа влияния появляются две карты: Outbound flows (потоки, уходящие от КЕ) и Inbound flows (приходящие к ней).
Расчёт рекурсивный: дойдя до следующего КЕ, iTop продолжает раскручивать уже его потоки и рисует их на том же графе. Combodo честно предупреждают, что из-за этого могут появляться петли, когда исходящий поток возвращается входящим в тот же самый КЕ. На больших базах это, подозреваю, будет весело ))
Услуги и тикеты
Статус услуги и подкатегории стал обязательным, по умолчанию implementation. Логика понятная: можно готовить будущие подкатегории, не показывая их клиентам. Но при апгрейде тут есть подводный камень, о нём ниже.
По тикетам стоит знать про связку родитель-потомок. У класса Incident появился внешний ключ parent_request_id на UserRequest, а у UserRequest соответствующая вкладка «Sub-Incidents». И запись, добавленная в журнал тикета, теперь автоматически копируется во все дочерние тикеты с префиксом, откуда она пришла (в приватном журнале со ссылкой на родителя, в публичном без, чтобы не плодить битые ссылки на портале).
Новый портал
А вот это по-настоящему заметное изменение, которое увидят конечные пользователи. Новый внешний вид пользовательского портала, который для 3.2 предлагался отдельным расширением, теперь встроен и полностью заменяет собой старый. Плюс на карточке тикета список вложений переехал выше журнала, чтобы не теряться в длинных переписках.
Разумеется, у этого есть обратная сторона: раз старый портал ушёл, все расширения, кастомизирующие его тему, перестают работать.
Администраторам: удаление расширений
Вот этого ждали давно. Часть расширений теперь можно удалять, и ради этого механизмы setup и upgrade переработали основательно: мастера установки и обновления выглядят иначе, есть проверка совместимости перед запуском установки (dry-run компиляция модели данных). В бэк-офисе появилась страница Extension management, где можно оценить, безопасно ли снести конкретное расширение.
Ещё добавили два новых триггера на добавление и удаление вложения у объекта, причём сам файл можно приложить к письму уведомления.
Миграция: на что смотреть в первую очередь
Полные заметки по миграции лежат здесь: 3.2.x to 3.3.0 Migration Notes [iTop Documentation]
Читать их стоит целиком, но я выделю то, что важнее всего.
PHP. Минимальная версия теперь 8.2.0, максимальная 8.4.x. Если вы сидите на 8.1, обновление PHP становится обязательным пунктом плана, а не пожеланием.
Конфликты XML в модели данных. Это главное следствие обновления CMDB и то, обо что реально можно споткнуться. Ваши кастомизации, сделанные расширениями, вполне могут конфликтовать с новой моделью. Первый конфликт вылезет прямо в мастере установки на фазе компиляции XML, и в сообщении будет указан модуль и узел. Сценариев два:
Node xxx/xxx/xxx already exists so cannot be created. Значит, ваша кастомизация ровно то же самое, что теперь приехало в стандартную поставку. Либо убираете свою кастомизацию, либо, если узел называется так же, а содержимое у вас другое, меняете_delta="define"на_delta="define_if_not_exists".Node yyy/yyy/yyy not found so cannot be modified/removed. Узел, который вы правили или удаляли, переехал или пропал. Если удаляли, кастомизацию просто убираем. Если правили, смотрим, достаточно ли заменитьredefineнаdefine, или придётся объявить ветку XML пошире.
И момент, который легко упустить: если вы своим расширением переопределяли presentation для классов CMDB, все новые улучшения отображения вы просто не увидите. Формально всё работает, но обновления как бы и нет.
Статусы услуг. Тот самый подводный камень. Все услуги и подкатегории со статусом undefined после обновления станут implementation. До обновления undefined на портале не показывались, а implementation показывались. После обновления логика переворачивается: implementation на портале больше не видны никому, кроме пользователей с профилем Service Manager. То есть при неаккуратном апгрейде часть каталога может внезапно исчезнуть из портала на глазах у заказчика. Обязательно проверьте до обновления, что у вас лежит в этих статусах.
Темы портала. Раз новый портал стал единственным, все старые расширения, кастомизирующие тему портала, перестают работать, их придётся переписывать по новому стандарту.
Триггеры на Attachment. Это уже после апгрейда. Если у вас настроены триггеры «на создание объекта» или «на удаление объекта» по классу Attachment, редактировать их больше нельзя, нужно заменить на новые классы триггеров из 3.3.
Остальное (изменения в базе, совместимые версии расширений, файл конфигурации, порядок отката на 3.2) есть по ссылке выше. Разработчикам расширений отдельно стоит открыть чек-лист и список breaking changes: Migrate an Extension to 3.3 [iTop Documentation]
Итого
Полный список изменений: iTop 3.3 Community [iTop Documentation]
Мой вывод такой: обновляться стоит, но не с наскока. Если у вас в проекте живёт заметная кастомизация модели данных, а у большинства из нас она живёт, то основная работа при переходе на 3.3 будет не в изучении новых фич, а в разборе конфликтов XML. Зато после этого CMDB наконец-то перестанет выглядеть так, будто её не трогали с позапрошлой мажорной версии.
Кто уже поднял стенд с бетой, делитесь впечатлениями в комментариях. Особенно интересно послушать, сколько конфликтов вылезло на вашей кастомизации и насколько больно было их разгребать.