Resources for the plan to implement upgrades in OpenStack Networking (Ocata Release)

1. Neutron Upgrade Strategy
Victor Morales

2. Agenda
• Upgrade - https://governance.openstack.org/reference/tags/assert_supports-upgrade.html
• Rolling upgrade - https://governance.openstack.org/reference/tags/assert_supports-rolling-
upgrade.html
• Zero downtime upgrade - https://governance.openstack.org/reference/tags/assert_supports-
zero-downtime-upgrade.html
• Plan - https://review.openstack.org/#/c/386685/
• Meetings - https://wiki.openstack.org/wiki/Meetings/Neutron-Upgrades-Subteam
• Zero impact upgrade - https://governance.openstack.org/reference/tags/assert_supports-zero-
impact-upgrade.html

3. Upgrade
That means it supports a controlled and planned upgrade process from release to
release.
Requirements:
• Configuration from release N-1 is supported in release N.
• Database schema updates are stable and ordered such that moving a database (with actual data in it) from
release N-1 to N is possible without data loss. http://docs.openstack.org/developer/neutron/devref/alembic_migrations.html
• A procedure for general upgrades of the project is defined and does not change substantially from cycle to
cycle. http://docs.openstack.org/developer/neutron/devref/upgrade.html
• Provides an upgrade impact section on the release notes page that highlights anything that must be done by
operators for each cycle outside the normal upgrade procedures. http://docs.openstack.org/releasenotes/neutron/
• Full stack integration testing is performed on every proposed commit to validate that cold upgrades from the
previous stable release are not broken. https://github.com/openstack-infra/project-
config/blob/master/jenkins/jobs/projects.yaml#L8051-L8080

4. Rolling Upgrade
That means that the code is installed and
deployed on many distributed systems and
can be upgraded avoiding a significant
downtime.
Requirements:
• Supports Upgrade.
• The project has a defined plan that allows operators to
roll out new code to subsets of services, eliminating
the need to restart all services on new code
simultaneously. In other words, “restarting all API
services together” is a reasonable restriction.
http://docs.openstack.org/developer/neutron/devref/upgrade.html
https://www.youtube.com/watch?v=UQLBw1_VGcU

5. Zero Downtime Upgrade
That means that the code is installed and
deployed on many distributed systems and
can be upgraded without downtime
(control plane entirely).
Requirements:
• Supports Rolling Upgrades.
• Requires services to completely eliminate API downtime
of the control plane during the upgrade. In other words,
“restarting all API services together” is not reasonable.
• While all requests to the control plane must be
eventually processed, performance degradation during
the upgrade is acceptable.

6. Zero Downtime Upgrade – Plan
• Isolate layer that has access to database (Oslo-Versioned Objects).
https://docs.google.com/spreadsheets/d/1FeeQlQITsZSj_wpOXiLbS36dirb_arX0XEWBdFVPMB8/edit#gid=1434170112
• Forbid new contract scripts in Ocata. The idea is to reach a point where unsafe
database operations (dropping tables and/or columns) become safe to execute it.
https://review.openstack.org/#/c/400239/
• Create a gating grenade job for running multiple neutron-server instances with
different versions. https://github.com/openstack-dev/grenade/blob/master/README.rst

7. Neutron – Zero Impact Upgrade
That means that the code is installed and deployed on many distributed systems
and can be seamlessly upgraded without downtime.
Requirements:
• Supports Zero Downtime Upgrades.
• Requires services to completely eliminate any perceivable performance penalty during the upgrade process.