Excerpts from na...@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. __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
