Open Stack

Excerpts from namnh at vn.fujitsu.com's message of 2017-02-28 09:52:13 +0000:
> Hi everyone,
> 
> Recently, there are many emails to discuss a topic that "Why are projects trying to avoid Barbican, still?" [0]. That is very an interesting topic. Now I would like to make a new topic related to Rolling upgrade. I am trying to find  information about the strategy to support rolling-upgrade for Barbican project. Unfortunately, there is not any results, if any, could you please update it for me. 
> 
> In my point of view, in order to support this feature, there will be three impacts which need to solve:
> 
> 1. API versioning:
> 
> Maybe, Barbican will have version two [1] so I think we should have a plan to still support version 1 on version 2. What do you about this point?
> 

Don't do it? Evolve v1 as needed, bud I'd recommend keeping whatever
users you currently have functional for as long as possible. Work with
the API-WG to make sure what you're doing is driving toward an API that
fits inside their best practices.

> 2. Database
> 
> - For OVO (Oslo version object) [2], I am wondering we should use OVO for this project. In my option, I am afraid that OVO is overkill for this project.
> - For DB upgrading, currently there are some files [3-4] to drop and alter column. This really should not have because there is not still have a solution in case of delete or alter DB. That why there is a rule that don't allow somebody to delete/alter DB in Nova and Neutron :) Do you think we should prepare for this?
> 

We should write this down somewhere if we haven't already but these are
the basic principles that will let live upgrades happen in your
database:

* Add columns with default values or make them nullable
* Drop columns and tables only after all releases that reference them are EOL.
* Never rename anything. Create new, migrate data, drop old after EOL.
* Make new code able to detect a partial migration and fall back to old
  behavior.