Обновление региона KeyStack ks2025.1.x → ks2026.2.1 вместе с ОС узлов

В этом разделе описаны шаги по обновлению версии KeyStack и ОС на узлах.

Здесь и далее вместо x в версии ks2025.1.x указывайте фактическую версию патча, установленную на узле.

Перед обновлением региона обязательно выполните обновление LCM до версии ks2026.2.1 (см. Обновление LCM ks2025.1.x → ks2026.2.1) — в его процессе пакет обновления upgrade-ks2026.2.1-{sberlinux|ubuntu}.tgz уже загружается на LCM-узел в папку /installer/update. Для регионов с Cloud SDS дополнительно требуется пакет upgrade-ks2026.2.1-sds1.4-sberlinux.tgz в той же папке.

Проверка работоспособности региона

Перед тем как приступать к обновлению, необходимо проверить состояние облачной инфраструктуры. Эта проверка необходима для минимизации рисков и поддержания стабильности системы. Проверка работоспособности региона позволяет убедиться, что виртуальные машины создаются и доступны по сети, что подтверждает работоспособность цепочки сервисов (MariaDB, HAProxy, Cinder, Nova, Neutron, Glance).

  1. Подключитесь к интерфейсу OpenStack CLI.

  2. Проверьте сетевую доступность всех узлов облака с помощью команды ping.

  3. Выполните команду openstack compute service list для проверки состояния вычислительных сервисов. Убедитесь, что все сервисы находятся в состоянии up.

  4. Выполните команду openstack volume service list для проверки состояния службы томов. Убедитесь, что все сервисы находятся в состоянии up.

  5. Выполните команду openstack server list для проверки состояния виртуальных машин.

  6. Используя Портал администратора или OpenStack CLI, а при использовании Ubuntu — также портал самообслуживания Horizon, создайте несколько ВМ с различными флейворами и выполните их живую миграцию.

Очистка устаревшего параметра Neutron

Начиная с ks2026.1 параметр global_physnet_mtu из конфигурационного файла config/neutron/neutron.conf добавлен в шаблон по умолчанию для Neutron. Поэтому можно удалить устаревшую строку из файла региона:

  1. Зайдите в веб-интерфейс GitLab.

  2. Перейдите в репозиторий региона project_k / deployments / <имя региона>.

  3. Откройте файл config/neutron/neutron.conf и удалите строку:

    global_physnet_mtu = {{ global_physnet_mtu }}
    
  4. Сохраните изменения.

Отключение сервисов DRS и HA

Перед началом обновления необходимо отключить сервисы DRS и HA.

Для деактивации DRS:

  1. Войдите в Портал администратора.

  2. Перейдите в раздел Динамический планировщик ресурсов > Задания.

  3. Деактивируйте все задания сервиса DRS.

Для деактивации HA:

  1. Зайдите на каждый Control-узел по SSH и выполните команду:

    # systemctl stop kolla-consul-container.service
    

Настройка и обновление RabbitMQ

Перед обновлением региона необходимо выполнить обновление конфигурации RabbitMQ.

Настройка параметров RabbitMQ:

  1. Зайдите в веб-интерфейс GitLab.

  2. Перейдите в репозиторий project_k / deployments / <имя региона>.

  3. Откройте на редактирование файл globals.d/rmq-tmp.yml, а если он отсутствует — создайте его. Исправьте или внесите новые строки:

    om_enable_queue_manager: true
    om_enable_rabbitmq_quorum_queues: true
    om_enable_rabbitmq_transient_quorum_queue: true
    om_enable_rabbitmq_stream_fanout: true
    om_enable_rabbitmq_high_availability: false
    
  4. Создайте новый пайплайн: Build > Pipelines > New pipeline.

  5. В переменной KOLLA_ARGS укажите значение --skip-tags loadbalancer,prometheus,victoriametrics,mariadb,rabbitmq,opensearch,memcache,grafana,drs,consul.

  6. В переменной KOLLA_ANSIBLE_DEPLOY_ACTION укажите значение genconfig.

  7. Запустите пайплайн New pipeline.

  8. Дождитесь завершения задач на этапе setup.

  9. Запустите задачу deploy на этапе deploy и дождитесь её завершения.

Остановите все службы OpenStack, использующие RabbitMQ, чтобы они пока не пытались пересоздать очереди.

  1. Создайте новый пайплайн: Build > Pipelines > New pipeline.

  2. В переменной KOLLA_ARGS укажите значение --tags common,keystone,cinder,nova,placement,glance,neutron,octavia,barbican,heat,adminui,hostmgmt,designate,ironic -e 'skip_stop_containers=["vhost"]' --yes-i-really-really-mean-it.

  3. В значение пустой переменной укажите stop, в имя переменной — KOLLA_ANSIBLE_DEPLOY_ACTION, оригинальную строку KOLLA_ANSIBLE_DEPLOY_ACTION удалите.

  4. Запустите пайплайн New pipeline.

  5. Дождитесь завершения задач на этапе setup.

  6. Запустите задачу deploy на этапе deploy и дождитесь её завершения.

Сброс состояния RabbitMQ:

  1. Зайдите на каждый Control-узел по SSH и выполните команду:

    # systemctl stop kolla-rabbitmq-container.service ; podman rm rabbitmq ; podman volume rm rabbitmq
    
  2. Создайте новый пайплайн: Build > Pipelines > New pipeline.

  3. В переменной KOLLA_ARGS укажите значение -e container_network_mode='host' -t rabbitmq.

  4. В переменной KOLLA_ANSIBLE_DEPLOY_ACTION укажите значение deploy.

  5. Запустите пайплайн New pipeline.

  6. Дождитесь завершения задач на этапе setup.

  7. Запустите задачу deploy на этапе deploy и дождитесь её завершения.

Запустите все службы OpenStack, использующие RabbitMQ, чтобы они заново создали соответствующие очереди:

  1. Создайте новый пайплайн: Build > Pipelines > New pipeline.

  2. В переменной KOLLA_ARGS укажите значение --tags common,keystone,cinder,nova,placement,glance,neutron,octavia,barbican,heat,adminui,hostmgmt,designate,ironic.

  3. В значение пустой переменной укажите deploy-containers, в имя переменной — KOLLA_ANSIBLE_DEPLOY_ACTION, оригинальную строку KOLLA_ANSIBLE_DEPLOY_ACTION удалите.

  4. Запустите пайплайн New pipeline.

  5. Дождитесь завершения задач на этапе setup.

  6. Запустите задачу deploy на этапе deploy и дождитесь её завершения.

  7. Зайдите на каждый узел по SSH и выполните команду:

    $ podman ps -a | grep -v Up
    
  8. Убедитесь, что вывод команды пустой либо содержит только пользовательские контейнеры. Все остальные контейнеры должны быть в запущенном состоянии (Up).

Перевод MariaDB в режим host network:

Примечание

Выполните этот шаг только если обновление производится на ОС SberLinux

  1. Зайдите на каждый Control-узел по SSH и проверьте, загружен ли модуль br_netfilter:

    $ lsmod | grep br_netfilter
    
  2. Если модуль отсутствует в выводе команды, загрузите его:

    $ sudo modprobe br_netfilter
    
  3. Выполните команду:

    # sysctl -w net.bridge.bridge-nf-call-iptables=0
    
  4. Создайте новый пайплайн: Build > Pipelines > New pipeline.

  5. В переменной KOLLA_ANSIBLE_DEPLOY_ACTION укажите значение mariadb_recovery.

  6. Запустите пайплайн New pipeline.

  7. Дождитесь завершения задач на этапе setup.

  8. Запустите задачу deploy на этапе deploy и дождитесь её завершения.

Переведите MariaDB в режим работы с host network:

  1. Создайте новый пайплайн: Build > Pipelines > New pipeline.

  2. В переменной KOLLA_ARGS укажите значение -e container_network_mode='host' -t mariadb.

  3. В переменной KOLLA_ANSIBLE_DEPLOY_ACTION укажите значение deploy.

  4. Запустите пайплайн New pipeline.

  5. Дождитесь завершения задач на этапе setup.

  6. Запустите задачу deploy на этапе deploy и дождитесь её завершения.

Если обновление региона выполняется в рамках миграции на новый LCM, перед переключением региона на новый LCM (см. Руководство по обновлению) добавьте новые CA-сертификаты нового LCM в конфигурацию региона на старом LCM и запустите полное развёртывание региона — это необходимо, чтобы во время переключения на новый LCM сервисы региона уже доверяли новым сертификатам:

  1. Зайдите в веб-интерфейс GitLab.

  2. Перейдите в репозиторий project_k / deployments / <имя региона>.

  3. Добавьте новые CA-сертификаты нового LCM в файл certificates/ca/ca-bundle.crt в репозитории региона на старом LCM.

  4. Создайте новый пайплайн: Build > Pipelines > New pipeline.

  5. В переменной KOLLA_ANSIBLE_DEPLOY_ACTION укажите значение deploy.

  6. Запустите пайплайн New pipeline.

  7. Дождитесь завершения задач на этапе setup.

  8. Запустите задачу deploy на этапе deploy и дождитесь её завершения.

Добавьте те же новые CA-сертификаты также в файл certificates/ca/ca-bundle.crt в репозитории региона на новом LCM.

Настройка GitLab

Измените конфигурацию пайплайна:

  1. Зайдите в веб-интерфейс GitLab.

  2. Перейдите в репозиторий project_k / deployments / <имя региона>.

  3. Откройте файл .gitlab-ci.yml в репозитории региона.

  4. В переменной KEYSTACK_RELEASE укажите версию релиза, на которую производится обновление — ks2026.2.1:

    KEYSTACK_RELEASE:
      value: &KEYSTACK_RELEASE ks2026.2.1
    

Настройте таймаут для пайплайнов:

  1. Перейдите в раздел Settings > CI/CD > General pipelines.

  2. Установите значение Timeout5h.

Обновление KeyStack на Control-узлах

Отредактируйте конфигурацию региона:

  1. Зайдите в веб-интерфейс GitLab.

  2. Перейдите в репозиторий project_k / deployments / <имя региона>.

  3. Откройте на редактирование файл inventory и измените группы:

    [tls-backend:children]
    control
    network
    compute
    storage
    monitoring
    
    [octavia:children]
    control
    
    [octavia-health-manager:children]
    network
    
    [octavia-worker:children]
    network
    
    [designate-mdns:children]
    designate
    
    [adminui-backend:children]
    control
    
    [adminui-frontend:children]
    control
    

    Добавьте группы:

    [nova-metadata:children]
    nova
    
    [prometheus-redfish-exporter:children]
    monitoring
    
    [prometheus-smartctl-exporter:children]
    monitoring
    control
    compute
    network
    storage
    
    [prometheus-pushgateway:children]
    monitoring
    
    [ovn-sb-db-relay:children]
    ovn-database
    
    [hostmgmt:children]
    control
    compute
    
    [vector:children]
    monitoring
    
    [adminui-hypervisor-exporter:children]
    compute
    
    [firewall:children]
    control
    network
    compute
    storage
    monitoring
    
    [temporal:children]
    control
    
    [patroni:children]
    control
    
    [keyvrm:children]
    control
    
    [keyvrm-server:children]
    keyvrm
    
    [keyvrm-worker:children]
    keyvrm
    
    [mcrouter:children]
    memcached
    

    Удалите группы:

    [adminui:children]
    control
    
    [swift:children]
    control
    
    # Swift
    [swift-proxy-server:children]
    swift
    
    [swift-account-server:children]
    storage
    
    [swift-container-server:children]
    storage
    
    [swift-object-server:children]
    storage
    
    [prometheus-hypervisor-exporter:children]
    compute
    
  4. Откройте на редактирование файл globals.d/REGION.yml, удалите параметр kolla_internal_fqdn_cert.

  5. Если в репозитории региона присутствует файл config/multipath.conf, удалите его.

  6. Обновите в Vault секрет adminui_gitlab_password (secret_v2 / deployments / <LCM FQDN> / <имя региона> / passwords_yml), указав в качестве значения текущий пароль технологической учётной записи ks-admin (secret_v2 / deployments / <LCM FQDN> / secrets / accounts).

  7. Откройте на редактирование файл globals.d/2526-tmp.yml и добавьте следующие параметры для выключения TLS на время проведения процесса обновления:

    Примечание

    Файл globals.d/2526-tmp.yml необходим только на время обновления. Если данные параметры уже включены в конфигурации ks2025.1.x, в любых конфигурационных файлах globals.d/*.yml, оставьте их без изменений. После завершения процесса обновления данные параметры можно убрать для включения функций безопасности.

    libvirt_tls: "no"
    rabbitmq_enable_tls: "no"
    opensearch_enable_tls_backend: "no"
    kolla_enable_mtls_backend: "no"
    nova_qemu_vnc_tls: "no"
    kolla_enable_tls_external: "yes"
    kolla_enable_tls_internal: "yes"
    kolla_enable_tls_backend: "no"
    kolla_enable_mtls_external: "no"
    kolla_enable_mtls_internal: "no"
    
    enable_selinux_profiles: "no"
    selinux_state: "permissive"
    enable_podman_ro: "no"
    
  8. Если в конфигурационных файлах globals.d/*.yml включены опции enable_keyvrm или enable_rbac_model, выключите их на время обновления, указав значения:

    enable_keyvrm: "no"
    enable_rbac_model: "no"
    

    В продукте по умолчанию выключены сервисы Octavia, Heat, Barbican и Designate. Если вы их используете, добавьте опции их включения:

    enable_octavia: "yes"
    enable_barbican: "yes"
    enable_designate: "yes"
    enable_heat: "yes"
    
  9. Откройте на редактирование файл globals.d/sds14-tmp.yml и добавьте следующие временные теги:

    Примечание

    Данный пункт предназначен только для обновления регионов, использующих Cloud SDS в качестве Storage.

    В этом файле фиксируются промежуточные версии компонентов nova-compute, cinder-volume и glance-api, необходимых для возможности обновления Cloud SDS 1.3 → 1.4 → 1.5.

    sds_14_tag: "ks2026.2.1-sds14-sberlinux"
    
    nova_compute_tag: "{{ sds_14_tag }}"
    cinder_volume_tag: "{{ sds_14_tag }}"
    glance_api_tag: "{{ sds_14_tag }}"
    

По умолчанию в ks2026.2.1 Prometheus Server выключен, включён VictoriaMetrics. Для продолжения работы с Prometheus Server добавьте в файл globals.d/REGION.yml параметр:

enable_prometheus_server: "yes"

Примечание

Если планируется использовать VictoriaMetrics, проверьте файлы globals.d/*.yml в репозитории региона на наличие параметра enable_victoriametrics: "no", оставшегося от предыдущих итераций конфигурации региона. Если такой параметр присутствует, удалите его или измените значение на "yes", иначе VictoriaMetrics не будет включён.

Запущенный сервис Prometheus Alertmanager заранее создаёт каталог данных Prometheus, что может приводить к ошибке переноса данных при выполнении пайплайна обновления региона на Control-узлах. Поэтому перед обновлением необходимо остановить сервис Prometheus Alertmanager, а также удалить автоматически созданную директорию prometheus/_data и всё её содержимое. Для этого перед запуском пайплайна обновления выполните следующие действия для каждого Control-узла по отдельности:

  1. Зайдите на каждый Control-узел по SSH и выполните команду:

    # systemctl stop kolla-prometheus_alertmanager-container.service
    

    Команда остановит запущенный на узле Prometheus Alertmanager.

  2. Выполните команду:

    # rm -rf /var/lib/docker/volumes/prometheus/_data/*
    

    Команда удалит соответствующую директорию.

    В случае использования Podman команда будет иметь следующий вид:

    # rm -rf /var/lib/containers/storage/volumes/prometheus/_data/*
    

По умолчанию в ks2026.2.1 выключена поддержка serial console. Для её дальнейшего использования добавьте в файл globals.d/REGION.yml параметр:

enable_nova_serialconsole_proxy: "yes"

Для загрузки образов KeyStack в кеш узлов выполните следующие действия:

Примечание

Данный шаг опциональный и нужен для ускорения выполнения основного пайплайна обновления. Процедура загрузки образов может идти в фоновом режиме. НЕ нужно дожидаться её завершения для перехода к следующим шагам.

  1. Зайдите в веб-интерфейс GitLab.

  2. Перейдите в репозиторий project_k / deployments / <имя региона>.

  3. Создайте новый пайплайн: Build > Pipelines > New pipeline.

  4. В переменной KOLLA_ANSIBLE_DEPLOY_ACTION укажите значение pull.

  5. Запустите пайплайн New pipeline.

  6. Дождитесь завершения задач на этапе setup.

  7. Запустите задачу deploy на этапе deploy.

Перед обновлением KeyStack на Control-узлах назначьте владельца директории логов ExaBGP:

  1. Зайдите на каждый Control-узел по SSH и выполните команду:

    # chown -R 43002 /var/log/kolla/exabgp
    

Для обновления KeyStack на Control-узлах выполните следующие действия:

  1. Зайдите в веб-интерфейс GitLab.

  2. Перейдите в репозиторий project_k / deployments / <имя региона>.

  3. Создайте новый пайплайн: Build > Pipelines > New pipeline.

  4. В переменной KOLLA_ARGS укажите значение --limit control,storage. Это обеспечит выполнение пайплайна только для Control- и Storage-узлов.

  5. В переменной KOLLA_ANSIBLE_DEPLOY_ACTION укажите значение upgrade.

  6. Запустите пайплайн New pipeline.

  7. Дождитесь завершения задач на этапе setup.

  8. Запустите задачу deploy на этапе deploy и дождитесь её завершения.

Для установки служб Портала администратора и hostmgmt-агента выполните следующие действия:

  1. Зайдите в веб-интерфейс GitLab.

  2. Перейдите в репозиторий project_k / deployments / <имя региона>.

  3. Создайте новый пайплайн: Build > Pipelines > New pipeline.

  4. Оставьте ветку по умолчанию, соответствующую установленному релизу.

  5. В переменной KOLLA_ARGS укажите значение --tags hostmgmt,adminui.

  6. В переменной KOLLA_ANSIBLE_DEPLOY_ACTION укажите значение deploy.

  7. Запустите пайплайн New pipeline.

  8. Дождитесь завершения задач на этапе setup.

  9. Запустите задачу deploy на этапе deploy и дождитесь её завершения.

Для удаления более неиспользуемых сервисов KeyStack выполните следующие действия:

  1. Убедитесь, что в файлах globals.d/*.yml отсутствуют параметры, удалите если есть:

    enable_drs: "yes"
    enable_consul: "yes"
    
  2. Зайдите на каждый Control-узел по SSH и выполните команду:

    # systemctl disable --now kolla-drs-container.service kolla-consul-container.service kolla-prometheus_consul_exporter-container.service ; rm -f /etc/systemd/system/kolla-{consul,drs,prometheus_consul_exporter}-container.service ; systemctl daemon-reload ; systemctl reset-failed ; podman rm consul drs prometheus_consul_exporter ; podman volume rm consul
    

    Команда остановит и удалит запущенные на узле службы consul (VMHA) и DRS.

  3. Для удаления Horizon (в версии на SberLinux больше не поставляется) зайдите на каждый Control-узел по SSH и выполните команду:

    # systemctl disable --now kolla-horizon-container.service ; rm -f /etc/systemd/system/kolla-horizon-container.service ; systemctl daemon-reload ; systemctl reset-failed ; podman rm horizon
    

    Команда остановит и удалит запущенную на узле службу Horizon.

  4. Зайдите на каждый Compute-узел по SSH и выполните команду:

    # systemctl disable --now kolla-consul-container.service ; rm -f /etc/systemd/system/kolla-consul-container.service ; systemctl daemon-reload ; systemctl reset-failed ; podman rm consul ; podman volume rm consul
    

    Команда остановит и удалит запущенную на узле службу consul (VMHA).

Обновление KeyStack на Network-узлах

Для обновления KeyStack на Network-узлах выполните следующие действия:

  1. Зайдите в веб-интерфейс GitLab.

  2. Перейдите в репозиторий project_k / deployments / <имя региона>.

  3. Создайте новый пайплайн: Build > Pipelines > New pipeline.

  4. В переменной KOLLA_ARGS укажите значение --limit network. Это обеспечит выполнение пайплайна только для Network-узлов.

  5. В переменной KOLLA_ANSIBLE_DEPLOY_ACTION укажите значение upgrade.

  6. Запустите пайплайн New pipeline.

  7. Дождитесь завершения задач на этапе setup.

  8. Запустите задачу deploy на этапе deploy и дождитесь её завершения.

Обновление ОС на Control-узлах

Для настройки репозитория ОС выполните следующие действия:

  1. Зайдите в веб-интерфейс GitLab.

  2. Перейдите в репозиторий project_k / deployments / <имя региона>.

  3. Создайте новый пайплайн: Build > Pipelines > New pipeline.

  4. Запустите пайплайн New pipeline.

  5. Дождитесь завершения задач на этапе setup.

  6. Запустите задачу bootstrap-servers на этапе deploy и дождитесь её завершения.

Перед обновлением ОС на Control-узлах проверьте возможность обновления выбранных узлов, как описано в разделе Проверка возможности обновления.

Для обновления ОС на Control-узлах выполните действия, описанные в разделе Обновление контроллеров, выбрав компонент обновления ОС.

Обновление ОС и KeyStack на Compute-узлах

Для возможности обновления Compute-узлов через Портал администратора укажите на каждом Compute-узле текущую версию релиза:

  1. Зайдите на Compute-узел по SSH.

  2. Выполните команду:

    # echo ks2025.1.x > /etc/keystack/ks_release
    

    где x — версия релиза, с которой выполняется обновление.

  3. Повторите действия для каждого Compute-узла.

Перед обновлением ОС на Compute-узлах проверьте возможность обновления выбранных узлов, как описано в разделе Проверка возможности обновления.

Для обновления KeyStack на Compute-узлах выполните действия, описанные в разделе Обновление гипервизоров, выбрав компонент обновления ОС+KeyStack.

Завершение обновления KeyStack

Примечание

Данный этап можно выполнять только после успешного обновления всех Compute-узлов

Для завершения обновления KeyStack и включения всех функций безопасности выполните следующие шаги:

  1. Удалите временные файлы из конфигурационного репозитория региона: globals.d/2526-tmp.yml и globals.d/rmq-tmp.yml.

  2. Включите опции enable_keyvrm и enable_rbac_model, указав в соответствующих файлах globals.d/*.yml значения:

    enable_keyvrm: "yes"
    enable_rbac_model: "yes"
    
  3. Включите опцию enable_vector_webhook_alertmanager, указав в файле globals.d/hpsm.yml значения:

    enable_vector_webhook_alertmanager: "yes"
    
  4. Зайдите в веб-интерфейс GitLab.

  5. Перейдите в репозиторий project_k / deployments / <имя региона>.

  6. Создайте новый пайплайн: Build > Pipelines > New pipeline.

  7. В переменной KOLLA_ANSIBLE_DEPLOY_ACTION укажите значение deploy.

  8. Запустите пайплайн New pipeline.

  9. Дождитесь завершения задач на этапе setup.

  10. Запустите задачу bootstrap-servers на этапе deploy и дождитесь её завершения.

  11. Запустите задачу deploy на этапе deploy и дождитесь её завершения.

Остановите и удалите сервисы контейнеров kolla-prometheus_hypervisor_exporter-container.service и kolla-prometheus_rabbitmq_exporter-container.service:

  1. Зайдите на каждый Compute-узел по SSH.

  2. Выполните команды:

    # systemctl disable --now kolla-prometheus_hypervisor_exporter-container.service ; rm -f /etc/systemd/system/kolla-prometheus_hypervisor_exporter-container.service ; systemctl daemon-reload ; systemctl reset-failed ; podman rm -f prometheus_hypervisor_exporter ; podman volume rm --force prometheus_hypervisor_exporter
    
  3. Зайдите на каждый Control-узел по SSH.

  4. Выполните команды:

    # systemctl disable --now kolla-prometheus_rabbitmq_exporter-container.service ; rm -f /etc/systemd/system/kolla-prometheus_rabbitmq_exporter-container.service ; systemctl daemon-reload ; systemctl reset-failed ; podman rm -f prometheus_rabbitmq_exporter ; podman volume rm --force prometheus_rabbitmq_exporter
    

Примечание

Данный этап можно выполнять только после успешного обновления кластера Cloud SDS до версии 1.4.х

Для завершения обновления драйверов Cloud SDS выполните следующие шаги:

  1. Удалите временный файл из конфигурационного репозитория региона globals.d/sds14-tmp.yml.

  2. Зайдите в веб-интерфейс GitLab.

  3. Перейдите в репозиторий project_k / deployments / <имя региона>.

  4. Создайте новый пайплайн: Build > Pipelines > New pipeline.

  5. В переменной KOLLA_ARGS укажите значение -t nova-cell,cinder,glance.

  6. В переменной KOLLA_ANSIBLE_DEPLOY_ACTION укажите значение deploy.

  7. Запустите пайплайн New pipeline.

  8. Дождитесь завершения задач на этапе setup.

  9. Запустите задачу host-config на этапе postconfig и дождитесь её завершения.

  10. Запустите задачу deploy на этапе deploy и дождитесь её завершения.

Каталог конфигурации Kolla автоматически перенесён с /etc/kolla на /opt/kolla. Удалите оставшиеся в /etc/kolla устаревшие файлы. Для этого зайдите на каждый узел по SSH и выполните команду:

# rm -rf /etc/kolla