openstack/octavia
Code Issues Proposed changes

Added versioning and migration mandates

Browse Source 
Updated HACKING.rst to include mandates
around API versioning and seamless migrations.

Change-Id: Iafb33d7a698b22a84a7b6167792e4d37aed110de
This commit is contained in:
Jorge Miramontes 2014-12-05 17:13:29 -06:00
parent 5d7e1ef9ca
commit 7a3f947081
1 changed files with 20 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

21
HACKING.rst
View File

@ -64,7 +64,7 @@ All APIs are versioned
----------------------
This includes "internal" APIs between Octavia components. Experience coding in
the Neutron LBaaS project has taught us that in a large project with many
heterogenous parts, throughout the lifecycle of this project, different parts
heterogeneous parts, throughout the lifecycle of this project, different parts
will evolve at different rates. It is important that these components are
allowed to do so without hindering or being hindered by parallel development
in other components.
@ -80,6 +80,25 @@ otherwise interfaced with by the new components.
Both of the above considerations can be allowed for if we use versioning of
APIs where components interact with each other.
Octavia must also keep in mind Neutron LBaaS API versions. Octavia must have
the ability to support multiple simultaneous Neutron LBaaS API versions in an
effort to allow for Neutron LBaaS API deprecation of URIs. The rationale is
that Neutron LBaaS API users should have the ability to transition from one
version to the next easily.
Upgrade and downgrade migrations will be supported
--------------------------------------------------
Whenever large operators conduct upgrades it is important to have a backup
plan in the form of downgrades. While upgrade migrations are commonplace,
often, downgrade migrations are ignored. Octavia will support migrations that
allow for seamless version to version upgrades/downgrades within the scope of a
major version.
For example, assume that an operator is currently hosting version 1.0 of
Octavia and wants to upgrade to Octavia version 1.1. A database migration will
consist of an upgrade migration and a downgrade migration that do not fail due
to foreign key constraints or other typical migration issues.
Scalability and resilience are as important as functionality
------------------------------------------------------------
Octavia is meant to be an *operator scale* load balancer. As such, it's usually