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. [1] https://docs.openstack.org/developer/barbican/contribute/database_migration s.html --Dave (dave-mccowan) On 2/28/17, 4:52 AM, "na...@vn.fujitsu.com" <na...@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 >point? > >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? > >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. > >[0] >http://lists.openstack.org/pipermail/openstack-dev/2017-January/thread.htm >l#110192 >[1] https://wiki.openstack.org/wiki/Barbican/v2 >[2] https://www.slideshare.net/davanum/ovo-deep-dive >[3] >https://github.com/openstack/barbican/blob/master/barbican/model/migration >/alembic_migrations/versions/3041b53b95d7_remove_size_limits_on_meta_table >_values.py >[4] >https://github.com/openstack/barbican/blob/master/barbican/model/migration >/alembic_migrations/versions/254495565185_removing_redundant_fields_from_o >rder.py >[5] >https://github.com/openstack/barbican/blob/master/barbican/queue/client.py >#L49 > > ------------------------------ >Best Regard, > >Nam NH >OpenStack team > > >__________________________________________________________________________ >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
