Open Stack

On Thu, 10 Mar 2022 at 14:50, Dan Smith <dms at danplanet.com> wrote:
>
> > "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?

Kolla Ansible uses rolling upgrades for most services. It doesn't
support full stop upgrades. I expect it wouldn't be too difficult to
implement, but it would be a shame to have two different upgrade
paths.

>
> --Dan