[TC][PTL][ops][all] Release cadence, deprecation, and testing
mark at stackhpc.com
Thu Mar 10 15:18:34 UTC 2022
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
More information about the openstack-discuss