Open Stack

> "This scheme does not necessarily dictate that live or rolling
> upgrades need to be supported between tick releases. Meaning RPC
> compatibility between N to N-1 guarantees can remain, resulting in
> deployments that are on a tick-tick release schedule requiring some
> downtime during an upgrade because components will be spanning more
> than two actual releases."
>
> From the perspective of deployment tools, this would mean needing to
> support two different upgrade strategies. Given the constraints around
> DB migrations, would it be too much effort for projects to also
> support N-2 to N RPC compatibility?

I can tell you it's much harder to do it for RPC than DB migrations. I
personally think it's too much to ask projects to move to that right
away, even though some may be able to do it now. It also has farther
reaches than you might expect, such as dependent components that change
over time (think OVS/OVN, libvirt, qemu).

It may just be the early morning and lack of caffeination, but I'm not
sure what the deployment concern is exactly. You rely entirely on live
rolling upgrades today? Presumably only for some of the services?

--Dan