From 7a3f9470815c279b23a2cd46fa683fb14e7bda7a Mon Sep 17 00:00:00 2001 From: Jorge Miramontes Date: Fri, 5 Dec 2014 17:13:29 -0600 Subject: [PATCH] Added versioning and migration mandates Updated HACKING.rst to include mandates around API versioning and seamless migrations. Change-Id: Iafb33d7a698b22a84a7b6167792e4d37aed110de --- HACKING.rst | 21 ++++++++++++++++++++- 1 file changed, 20 insertions(+), 1 deletion(-) diff --git a/HACKING.rst b/HACKING.rst index 7d932013ce..178713b66d 100644 --- a/HACKING.rst +++ b/HACKING.rst @@ -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