Open Stack

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:clint at 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 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.
  

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev