6.1 Updating Oracle OpenStack for Oracle Linux Packages

Perform the following steps to update the Oracle OpenStack for Oracle Linux packages and deployment environment.

Shut down all running instances in the deployment.
(All nodes) Ensure you have a backup of the Docker file system mounted on /var/lib/docker.
(Compute nodes) If you store ephemeral virtual machine data on the compute nodes, ensure you have a backup of the data mounted on /var/lib/kolla.
Ensure that you have a backup of the OpenStack databases.
See Section 8.5, “Backing Up and Restoring the Database” for details.
(All nodes) Ensure the target nodes are prepared for the new release.
Configure the Yum repositories on the nodes so that they can download the Release 3.0 packages, and disable the Release 2.1 repository.
For Oracle Linux nodes, ensure that you have also upgraded the Python Docker libraries.
See Section 3.5, “Preparing Oracle Linux Nodes” and Section 3.6, “Preparing Oracle VM Server Nodes” for details.
(All Nodes) Update the Oracle OpenStack for Oracle Linux preinstallation package (openstack-kolla-preinstall).
```
# yum update openstack-kolla-preinstall
```
(Master node) Update the Oracle OpenStack for Oracle Linux CLI package (openstack-kollacli) and the Utilities package (openstack-kolla-utils).
```
# yum update openstack-kollacli
# yum update openstack-kolla-utils
```
(Master node) Manually upgrade customized configuration files.
After you perform an upgrade of the openstack-kollacli package, there may be some copies of configuration files, with either the suffix rpmsave or rpmnew. These files are created by the package upgrade if the configuration file of the new package differs from the configuration file on disk. This may occur if you have non-default, customized configuration files.
Depending on the configuration of the package, you may have one of two types of backed up configuration files:
- The original file is saved to *.rpmsave during the package upgrade and the new configuration file is used.
- The original file is kept during the upgrade, and a new configuration file is created by the upgrade is saved to *.rpmnew.
To search for any changed configuration files on the master node:
```
# find /etc/kolla | grep rpmsave
# find /etc/kolla | grep rpmnew
```
Compare any resulting configuration files changes using the diff utility, for example:
```
# diff /etc/kolla/config/cinder.conf /etc/kolla/config/cinder.conf.rpmsave 
```
If you want to include your customized configuration in the upgrade deployment, copy the *.rpmsave file to the original name of the configuration file (or merge the content as appropriate).
To use the new configuration file, copy the *.rpmnew file (or merge the content as appropriate) to the original name of the configuration file.
Important
To enable the upgrade, the openstack-kollacli package creates a customized configuration file for the Nova service at /etc/kolla/config/nova.conf. This file contains:
```
[neutron]
username = nova
```
If you have made customizations to the /etc/kolla/config/nova.conf file, you should review the content of the nova.conf.rmpsave file and merge the contents with the new nova.conf file.
(Master node) Regenerate the Swift rings.
Only perform this step if you are using Swift object storage.
In this release, the Swift object storage service uses the storage network (storage_interface) for storage data operations. In previous releases, the management/API network (api_interface) was used. By default, the storage network and the management/API network are the same network (the storage_interface and api_interface properties are mapped to the network_interface property). You might need to recreate the Swift rings if the IP addresses of the storage hosts are different as a result of this change. For details about creating Swift rings, see Section 4.12.2, “Building the Swift Rings”.