[openstack-dev] [barbican] Rolling upgrade in Barbican project

Dave McCowan (dmccowan) dmccowan at cisco.com
Tue Feb 28 14:06:40 UTC 2017

Hi Nam--
   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. [1]
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.


--Dave (dave-mccowan)

On 2/28/17, 4:52 AM, "namnh at vn.fujitsu.com" <namnh at vn.fujitsu.com> wrote:

>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
>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
>- 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?
>3. RPC
>There is not version parameter when sending AMQP [5]. 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.
>[1] https://wiki.openstack.org/wiki/Barbican/v2
>[2] https://www.slideshare.net/davanum/ovo-deep-dive
> ------------------------------
>Best Regard,
>Nam NH
>OpenStack team
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe

More information about the OpenStack-dev mailing list