Hi Client, > 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. Thanks for your advice, surely I will remember it.
> 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. I got it, but I just consider one thing about deleting(altering) table/column. Could you please refer this mailing-list [1] for more detail. [1] http://lists.openstack.org/pipermail/openstack-dev/2017-March/113073.html -----Original Message----- From: Clint Byrum [mailto:cl...@fewbar.com] Sent: Wednesday, March 01, 2017 1:57 AM To: openstack-dev Subject: Re: [openstack-dev] [barbican] Rolling upgrade in Barbican project 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 __________________________________________________________________________ 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
