You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

This article summarizes the steps required to upgrade from the queens release to the rocky release of openstack.

Prerequisites:

  • This documents expects that your cloud is deployed with the latest queens tag(vQ.n.n) of the ntnuopenstack repository.
  • Your cloud is designed with one of the two architectures:
    • Each openstack project have their own VM(s) for their services
  • You have a recent mysql backup in case things go south.
  • If you want to do a rolling upgrade, the following key should be set in hiera long enough in advance that all hosts have had an puppet-run to apply it:
    • nova::upgrade_level_compute: 'queens'

VM-based architecture

If you use the VM based infrastructure you have the luxury of upgrading one service at a time and test that the upgrade works before doing the next service. This allows for ~zero downtime. If the services are redundantly deployed it is also very easy to do a rollback.

The recommended order to upgrade the services are listed below:

Keystone

This is the zero downtime approach

Before you begin:

  • Set keystone::sync_db: false globally in hiera
  • Set keystone::enabled: false in hiera for the node that you plan to run the rolling upgrade from
  • Login to a mysql node, start the mysql CLI, and run set global log_bin_trust_function_creators=1;

On the node you plan to run the rolling upgrade from

  1. Run puppet with the rocky modules/tags
  2. Stop apache2 and puppet
  3. Purge the keystone package
  4. Run apt dist-upgrade
  5. Run puppet again
    1. This will re-install keystone (ensure that apache2 does not start - should be ensured by puppet as of the enable: false flag in hiera)
  6. Run keystone-manage doctor and ensure nothing is wrong
  7. Run keystone-manage db_sync --expand
    1. Returns nothing
  8. Run keystone-manage db_sync --migrate
    1. Returns nothing
  9. At this point, you may restart apache2 on this node
  10. Upgrade keystone on the other nodes, one at a time
    1. Basically run step 1-5 on the other nodes
  11. When all nodes are upgraded, perform the final DB sync
    1. keystone-manage db_sync --contract
  12. Remove the keystone::enabled: false hiera key from the first node, and re-run puppet
  13. Remove the keystone::sync_db: false key from hiera


  • No labels