[ English | Indonesia | русский ]

Незначительное обновление версии

Обновление OpenStack-Ansible между младшими версиями требует обновления клона репозитория до последней версии, обновления ролей Ansible, а затем запуска плейбука на целевых узлах. В этом разделе приведены инструкции по выполнению этих задач.

Предварительные условия

Чтобы избежать проблем и упростить поиск неисправностей во время обновления, отключите роль усиления безопасности, установив переменную apply_security_hardening в значение False в файле user_variables.yml, и создайте резервную копию вашей установки OpenStack-Ansible.

Выполнение минорного обновления версии

Для минорного обновления обычно требуются следующие действия:

  1. Измените каталог на клонированный корневой каталог репозитория:

    # cd /opt/openstack-ansible

  2. Убедитесь, что ваш код OpenStack-Ansible находится на последней версии с меткой 2025.2 (Flamingo):

    # git checkout master

  3. Обновите все зависимые роли до последней версии:

    # ./scripts/bootstrap-ansible.sh

  4. Перейдите в каталог плейбука:

    # cd playbooks

  5. Обновите хосты:

    # openstack-ansible openstack.osa.setup_hosts -e package_state=latest

  6. Обновите инфраструктуру:

    # openstack-ansible -e rabbitmq_upgrade=true \
openstack.osa.setup_infrastructure

  7. Обновите все службы OpenStack:

    # openstack-ansible openstack.osa.setup_openstack -e package_state=latest

Примечание

Вы можете ограничить обновления для определенных компонентов OpenStack. Подробности см. в следующем разделе.

Обновление определенных компонентов

Вы можете ограничить обновления для определенных компонентов OpenStack, запустив каждый из плейбуков компонентов в зависимости от групп.

Например, вы можете обновить только вычислительные узлы, выполнив следующую команду:

# openstack-ansible openstack.osa.nova --limit nova_compute

Чтобы обновить только один вычислительный узел, выполните следующую команду:

# openstack-ansible openstack.osa.nova --limit <node-name>

Примечание

Игнорирование метки nova-key необходимо для того, чтобы не собирать ключи на всех вычислительных хостах.

Чтобы увидеть, какие хосты принадлежат к тем или иным группам, используйте скрипт openstack-ansible-inventory-manage, чтобы показать все группы и их хосты. Например:

  1. Измените каталог на корневой каталог клона репозитория:

    # cd /opt/openstack-ansible

  2. Посмотрите все группы и хосты, принадлежащие к ним:

    # openstack-ansible-inventory-manage -G

  3. Посмотрите все хосты и группы, к которым они принадлежат:

    # openstack-ansible-inventory-manage -g

Чтобы узнать, на каких хостах запускается плейбук и какие задачи выполняются, выполните следующие команды (например):

  1. Посмотрите список хостов в группе nova_compute, на которых работает плейбук:

    # openstack-ansible openstack.osa.nova --limit nova_compute \
                                        --list-hosts

  2. Посмотрите задания, которые выполняются на хостах в группе nova_compute:

    # openstack-ansible openstack.osa.nova --limit nova_compute \
                                        --skip-tags 'nova-key' \
                                        --list-tasks

Обновление определенного компонента в пределах одной версии OpenStack-Ansible

Иногда может потребоваться установить последние обновления безопасности или исправления ошибок для службы, оставаясь на той же стабильной ветке. Это можно сделать, переопределив ветку установки Git для этой службы, которая предписывает OpenStack-Ansible извлечь самый последний код из ветки, которую вы уже отслеживаете. Однако, использование веток напрямую, как <service>_git_install_branch, крайне не рекомендуется. При каждом повторном запуске плейбука служба может обновляться до более нового коммита, что может привести к несогласованности версий между хостами (например, при последующем добавлении нового вычислительного узла).

Поэтому рекомендуется взять SHA-хэш HEAD-коммита нужной стабильной ветки и задать его явно. Чтобы найти последний SHA-хэш ветки stable/2025.1, выполните (например, для Nova):

git ls-remote https://opendev.org/openstack/nova refs/heads/stable/2025.1

И используйте этот SHA в своей конфигурации, чтобы гарантировать единообразие версий на всех хостах в вашем user_variables.yml:

nova_git_install_branch: {{SHA}}

И запустите:

openstack-ansible openstack.osa.nova --tags nova-install

Плейбук извлечёт и установит код из указанной ветки или коммита SHA, применяя последние исправления и патчи, как указано. Использование закреплённого SHA обеспечивает согласованность версий на всех хостах, а прямое отслеживание ветки всегда будет загружать её текущий HEAD.

Мы можем проверить версию службы до и после обновления (не забудьте загрузить необходимые переменные среды):

$ ansible -m shell -a '/openstack/venvs/nova-{{ openstack_release }}/bin/pip3 freeze | grep nova' nova_all
infra1-nova-api-container-e5dbbe38 | CHANGED | rc=0 >>
nova==31.0.1.dev12
infra2-nova-api-container-0c5d0203 | CHANGED | rc=0 >>
nova==31.0.1.dev12
infra3-nova-api-container-d791a43e | CHANGED | rc=0 >>
nova==31.0.1.dev12
compute | CHANGED | rc=0 >>
nova==31.0.1.dev12

После обновления до последних патчей в той же ветке:

$ ansible -m shell -a '/openstack/venvs/nova-{{ openstack_release }}/bin/pip3 freeze | grep nova' nova_all
infra1-nova-api-container-e5dbbe38 | CHANGED | rc=0 >>
nova==31.1.1.dev9
infra2-nova-api-container-0c5d0203 | CHANGED | rc=0 >>
nova==31.1.1.dev9
infra3-nova-api-container-d791a43e | CHANGED | rc=0 >>
nova==31.1.1.dev9
compute | CHANGED | rc=0 >>
nova==31.1.1.dev9

Примечание

Этот подход применим не только к Nova. Вы можете применить тот же метод к любой другой службе OpenStack, управляемой OpenStack-Ansible, переопределив соответствующую переменную <service>_git_install_branch.

Прежде чем продолжить, всегда проверяйте, что ветвь обновлена ​​и совместима с остальной частью вашего развертывания.