[openstack-dev] [barbican] Rolling upgrade in Barbican project

Clint Byrum clint at fewbar.com
Tue Feb 28 18:57:07 UTC 2017

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

* 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

More information about the OpenStack-dev mailing list