What’s changed in RPCO v13.1#

The following items have changed in Rackspace Private Cloud Powered By OpenStack (RPCO) v13.1:

  • The upgrade_elasticsearch_pre.yml playbook upgrades the legacy Elasticsearch data and prepares the cluster for the upgrade of the Elasticsearch packages. Because of some inconsistencies in the legacy Elasticsearch mappings, all Elasticsearch data must be reindexed into indices with the updated 2.x compatible mappings. Included with the upgrade tasks is a Python wrapper to monitor and control the reindexing process. We recommended that you reindex all indices prior to the current date before beginning the upgrade. For more information on how to reindex the existing Elasticsearch indices, see the RPCO v13.1 Upgrade Guide.

  • The Elasticsearch upgrade process requires that the logging_upgrade OSA variable be set to True.


    Data corruption can occur if this value is not set to True.

  • If you are upgrading from an environment that has L3HA enabled, previous HA routers, networks, and ports will persist. Manually deleting these resources could cause the router namespaces to disappear, which would in turn cause network down time.

    For more information, see bug 1149 or the “What’s changed” section in the RPCO v13.0 Release Notes.

  • Because of the hostname changes in Mitaka, the Ceph monitors and OSDS configuration files must be updated. You must back up, destroy, and re-create the monitors, and then rejoin them to the cluster serially.

    • When the monitors are re-created during the upgrade procedure, the Ceph monitors have bind mounts to the hosts, which makes backing up the monitors easier in the future.

  • The ssh_delay OSA variable has been changed to 60 from the OSA default of 5.

  • By default, security hardening is applied on an upgrade. To prevent its application, add apply_security_hardening: false to the /etc/openstack_deploy/user_osa_variables_overrides.yml file. This skips the security-hardening.yml OSA playbook during an upgrade.

  • Based on feedback from Support, the default value for neutron_l2_population has been overridden to True.

  • The new configuration file layout requires a manual migration of overrides to a new location. If you do not perform this migration, some overrides might not be set and unknown behavior could occur.

    Run the migrate-yaml.py script and verify that the output is correctly building your overrides files. We recommend putting RPCO specific overrides in the /etc/openstack-deploy/user_rpco_variables_overrides.yml file and the OSA specific overrides in the /etc/openstack-deploy/user_osa_variables_overrides.yml file.

    The secrets files must be combined and migrated manually to the /etc/openstack_deploy/user_rpco_secrets.yml file. For more information on how to migrate variables, see the RPCO v13.1 Upgrade Guide.

  • The rpc-pre-upgrades.yml playbook performs the pre-upgrade steps as outlined in the RPCO Maintenance Template. Output from the steps are stored in the $HOME/rpc13-upgrade-<date-stamp> file on the deployment server. Examine these files closely before proceeding with the upgrade.

  • After the upgrade has been performed, the MaaS CLI tools and dependencies are installed in their own virtual environment in /openstack/venv/maas-. MaaS plug-ins use the virtual environment and no longer use the packages in the global environment.

  • The default value for the ARP responder was changed upstream for the ML2 and Linux Bridge agent. The logical network now uses traditional flood and learn behavior through the overlay. RPCO handles this change between the points in time when this default value changed.

    During an upgrade, existing Virtual Extensible LAN (VXLAN) devices retain their old setup and are not affected by changes to this value.

    For older devices created with the Liberty agent, apply this change with the following steps:

    1. Remove the VXLAN device.

    2. Restart the Mitaka agent. When it restarts, the agent re-creates the VXLAN devices with the current settings.

  • The default_subnet_pools option has been deprecated and will be removed in the Newton release. The same functionality is now provided by setting the is_default attribute on subnetpools to True by using the API or client.

  • Kibana has been upgraded to version 4. This upgrade includes changes to the default dashboard and all new features.