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

Pemutakhirkan versi minor

Upgrades between minor versions of OpenStack-Ansible require updating the repository clone to the latest minor release tag, updating the Ansible roles, and then running playbooks against the target hosts. This section provides instructions for those tasks.

Prasyarat

To avoid issues and simplify troubleshooting during the upgrade, disable the security hardening role by setting the apply_security_hardening variable to False in the user_variables.yml file, and backup your OpenStack-Ansible installation.

Jalankan pemutakhiran versi kecil

Pemutakhiran minor biasanya membutuhkan langkah-langkah berikut:

  1. Ubah direktori ke direktori root repositori kloning:

    # cd /opt/openstack-ansible

  2. Pastikan kode OpenStack-Ansible Anda ada di 2025.2 (Flamingo) terbaru rilis yang ditandai (tagged):

    # git checkout master

  3. Perbarui semua peran dependen ke versi terbaru:

    # ./scripts/bootstrap-ansible.sh

  4. Ubah ke direktori playbook:

    # cd playbooks

  5. Perbarui host:

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

  6. Perbarui infrastruktur:

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

  7. Perbarui semua layanan OpenStack:

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

Catatan

Anda dapat membatasi pemutakhirkan pada komponen OpenStack tertentu. Lihat bagian berikut untuk detailnya.

Mutakhirkan komponen tertentu

Anda dapat membatasi pemutakhiran pada komponen OpenStack tertentu dengan menjalankan masing-masing playbook komponen terhadap grup.

Misalnya, Anda hanya dapat memperbarui host Compute dengan menjalankan perintah berikut:

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

Untuk memperbarui hanya satu host Compute, jalankan perintah berikut:

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

Catatan

Melewati tag nova-key diperlukan sehingga kunci pada semua host Compute tidak terkumpul.

To see which hosts belong to which groups, use the openstack-ansible-inventory-manage script to show all groups and their hosts. For example:

  1. Ubah direktori ke direktori root clone repositori:

    # cd /opt/openstack-ansible

  2. Tunjukkan semua grup dan host mana yang menjadi milik mereka:

    # openstack-ansible-inventory-manage -G

  3. Tunjukkan semua host dan grup tempat mereka berada:

    # openstack-ansible-inventory-manage -g

Untuk melihat host mana yang dijalankan oleh playbook, dan untuk melihat tugas mana yang dilakukan, jalankan perintah berikut (misalnya):

  1. Lihat beberapa host di grup nova_compute dimana playbook bertentangan:

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

  2. Lihat tugas yang dijalankan pada host di grup nova_compute:

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

Upgrading a specific component within the same OpenStack-Ansible version

Sometimes you may need to apply the latest security patches or bug fixes for a service while remaining on the same stable branch. This can be done by overriding the Git installation branch for that service, which instructs OpenStack-Ansible to pull the most recent code from the branch you are already tracking. But using branches directly as <service>_git_install_branch is highly discouraged. Every time the playbook is re-run, the service may be upgraded to a newer commit, which can lead to inconsistent versions between hosts (for example, when adding a new compute node later).

So the recommended practice is to take the HEAD commit SHA of the desired stable branch and set it explicitly. To find the latest SHA of the stable/2025.1 branch, you can run (e.g. for Nova):

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

And use that SHA in your configuration to ensure consistent versions across all hosts in your user_variables.yml:

nova_git_install_branch: {{SHA}}

And run:

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

The playbook will fetch and install the code from the specified branch or commit SHA, applying the latest patches and fixes as defined. Using a pinned SHA ensures consistent versions across all hosts, while following the branch directly will always pull its current HEAD.

We can verify the version of the service before and after the upgrade (don't forget to load required environment variables):

$ 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

After the upgrade to the latest patches in the same branch:

$ 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

Catatan

This approach is not limited to Nova. You can apply the same method to any other OpenStack service managed by OpenStack-Ansible by overriding its corresponding <service>_git_install_branch variable.

Always ensure that the branch is up-to-date and compatible with the rest of your deployment before proceeding.