Open Stack

On 01/18/2016 03:31 PM, Duncan Thomas wrote:
> On 5 January 2016 at 18:55, Ryan Rossiter <rlrossit at linux.vnet.ibm.com
> <mailto:rlrossit at linux.vnet.ibm.com>> wrote:
>
>     This is definitely good to know. Are you planning on setting up
>     something off to the side of o.vo within that holds a dictionary
>     of all values for a release? Something like:
>
>     {‘liberty’: {‘volume’: ‘1.3’, …},
>      ‘mitaka’: {‘volume’: ‘1.8’, …}, }
>
>     With the possibility of replacing the release name with the RPC
>     version or some other version placeholder. Playing devil’s
>     advocate, how does this work out if I want to be continuously
>     deploying Cinder from HEAD?
>
>
> As far as I know (the design has iterated a bit, but I think I'm still
> right), there is no need for such a table - before you start a rolling
> upgrade, you call the 'pin now' api, and all of the services write
> their max supported version to the DB. Once the DB is written to by
> all services, the running services can then read that table and cache
> the max value. Any new services bought up will also build a max volume
> cache on startup. Once everything is upgraded, you can call 'pin now'
> again and the services can figure out a new (hopefully higher) version
> limit.
>

You're right, that was the initial design we've agreed on in Liberty.
Personally I'm now more in favor of how it's implemented in Nova [1].
Basically on service startup RPC API is pinned to the lowest version
among all the managers running in the environment. I've prepared PoC
patches and successfully executed multiple runs of Tempest on deployment
with Mitaka's c-api and mixed Liberty and Mitaka c-sch, c-vol, c-bak
(two of each service).

I think we should discuss this in details at the mid-cycle meetup next week.

[1] https://blueprints.launchpad.net/nova/+spec/service-version-behavior
[2] https://review.openstack.org/#/c/268025/
[3] https://review.openstack.org/#/c/268026/