[openstack-dev] [barbican] Rolling upgrade in Barbican project
namnh at vn.fujitsu.com
namnh at vn.fujitsu.com
Wed Mar 1 02:52:23 UTC 2017
Thanks for your reply. I would like to answer your email like below:
> Offline rolling upgrades is part of the current Barbican project
Do you mean that Barbican supported to upgrade? Currently, there are 4 main level during upgrade 
1. Support upgrade
2. Support rolling upgrade
3. Support zero downtime
4. Support zero impact
> 2) Database Upgrades
> I think we have good support for doing database upgrades when upgrading the version of Barbican. We offer a barbican-db-manage script to handles upgrades.  It would be good to improve the documentation on this process. It would also be good to add a gate job to automatically test upgrading Barbican.
Yes, I tested upgrading DB and it works well. However, I am considering a point that Barbican still allow our to delete/alter table/column in DB by upgrading, that is a problem if we want to support rolling upgrade. For example, in Neutron, there was a blueprint  and a spec to describe this. You can see the description of the blueprint is """Currently pretty much every major upgrade requires full shutdown for all neutron-server instances for the time while upgrade process is running. The downtime is due to the need to run alembic scripts that modify schema and transform data. Neutron-server instances are currently not resilient to working with older schema. We also don't make an effort to avoid 'contract' migrations""".
> 3) RPC version
So I am wondering that Barbican have a plan to do this on this cycle(Pike)?
From: Dave McCowan (dmccowan) [mailto:dmccowan at cisco.com]
Sent: Tuesday, February 28, 2017 9:07 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [barbican] Rolling upgrade in Barbican project
Thanks for writing. Offline rolling upgrades is part of the current Barbican project. Better support and documentation for upgrades would be a welcome addition.
1) API Versioning
Currently, Barbican only has one API version. The wiki you reference is an old list of ideas that we started collecting for when/if we create a V2. I agree, that as part of any new API version, we'll need to consider upgrades and backwards compatibility.
2) Database Upgrades
I think we have good support support for doing database upgrades when upgrading the version of Barbican. We offer a barbican-db-manage script to handles upgrades.  It would be good to improve the documentation on this process. It would also be good to add a gate job to automatically test upgrading Barbican.
3) RPC Versioning
Adding versioning to our RPC message would be good to future-proof our design. Perhaps we should leave the message objects stable for now, and add a version field in the future when/if a scenario occurs that requires us to change these message objects.
On 2/28/17, 4:52 AM, "namnh at vn.fujitsu.com" <namnh at vn.fujitsu.com> wrote:
>Recently, there are many emails to discuss a topic that "Why are
>projects trying to avoid Barbican, still?" . 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  so I think we should have a
>plan to still support version 1 on version 2. What do you about this
>- For OVO (Oslo version object) , I am wondering we should use OVO
>for this project. In my option, I am afraid that OVO is overkill for
>- 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?
>There is not version parameter when sending AMQP . This parameter is
>really necessary to distinguish the message is Ocata or Pike.
>That is some points in my option, what do you think we should have to
>plan to support this feature and I am very glad to discuss this topic
>with you on this thread mailing-list.
>___ OpenStack Development Mailing List (not for usage questions)
>OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
More information about the OpenStack-dev