[openstack-dev] [barbican] Rolling upgrade in Barbican project
Dave McCowan (dmccowan)
dmccowan at cisco.com
Tue Feb 28 14:06:40 UTC 2017
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 this
>- 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)
>Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
More information about the OpenStack-dev