Open Stack

Thanks for such detailed explanation, that makes sense indeed for me.

On Sat, Jun 24, 2023, 00:58 <smooney at redhat.com> wrote:

> On Fri, 2023-06-23 at 17:08 +0200, Dmitriy Rabotyagov wrote:
> > I wonder what is the reason for such diversification between B and C
> then?
> the short version is nova maintains two version contants for libvirt/qemu
> version in
> our code base. our current minium and our future minium so in the b cycle
> we are updating
> our current minium to what was our planned future miniutm and we are
> decided what
> to set the next annouched future minium too.
> > As C will be the next SLURP [1] release, meaning A->C upgrades must be
> > supported. So doing a minimal version bump 2 times doesn't make too
> > much sense to me, as long as any platform we have in PTI is not
> > affected.
> > Also my assumption was that all version bumps (or deprecations)
> > ideally should happen during non-SLURP releases.
> there is actully no agreement on that specifically but if we were to adapt
> nova policy
> to the slurp release cycle we would want to ensure when we select a next
> min
> it is shiped in the release notes fo a SLUP release and then yes the
> actual bump would happen
> the non slurp or next sulrp release. The cadnace of when we actully do a
> min bump
> tend to be every 2-4 releases.
> >
> > So what's the reason not to do this now and wait for C?
> we cant with out breaking our policy of alwasy providing at least one
> release notice
> before increaing our min.
>
> the version bump we are doing for bobcat was ment to be done in zed and
> antelope
> but got pushed out for differnt reasosn. mainly gate instablity and review
> badnwith.
>
> we may or may not actully do a version bump in C but by advertising that
> our future min verions
> will move to that shiped in ubuntu 22.04. it means if we do decided to
> bump in C we will actully
> be testing with the min supported version. canonical assuming they hold to
> there normally pattern will be release
> C/2024.1 on 24.04 an also supproting it on 22.04 for upgrades. We will
> want to keep support for 22.04 libvirt/qemu to
> ensure a smoth upgrade. but we can raise our min to aling whith what is
> shiped on 22.04 and what is tested in our ci
> by doing a second version bump in ci.
>
> The D/2024.2 cycle should see us move to 24.04 as a new base for ci and we
> can revaluate moving to somehting
> more modern again at that point.
>
> nova generally support quite a broad range of libvirt/qemu version so
> while it help reduce our tech debt when
> we increase our min version, in reality most distros end up shipping a
> much newer version then we technically support.
>
> >
> > [1]
> https://governance.openstack.org/tc/resolutions/20220210-release-cadence-adjustment.html
> >
> > пт, 23 июн. 2023 г. в 16:20, Thomas Goirand <zigo at debian.org>:
> > >
> > > Hi,
> > >
> > > Repeating what I wrote on IRC.
> > >
> > > On 6/23/23 16:10, Kashyap Chamarthy wrote:
> > > >    - Debian 11 (Bullseye):
> > > >      - libvirt: 7.0.0-3+deb11u2
> > > >      - qemu: 5.2+dfsg-11+deb11u2
> > >
> > > As far as Debian is concerned, the last version of OpenStack supported
> > > on Bullseye was Zed (like every 4 OpenStack release and for each new
> > > Debian release, there's a version of Zed that I maintain for both
> > > Bullseye and Bookworm, to offer easier transitions). Everything above
> > > that, needs to run on bookworm. I will *not* do any backport for Debian
> > > 11, which is already the past for me. In this case, for Debian 12 (aka:
> > > Bookworm) we have:
> > >
> > >     - Debian 11 (Bullseye):
> > >       - libvirt: 9.0.0
> > >       - qemu: 7.2
> > >
> > > So feel free to bump up to that. If needed, I can even do backports
> > > myself for these key components, whenever they reach Testing. Probably
> > > soon libvirt 9.4.0 (which is already in Experimental, and that will
> > > probably soon reach Unstable, then testing).
> > >
> > > I hope this helps,
> > > Cheers,
> > >
> > > Thomas Goirand (zigo)
> > >
> > >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230624/28ef4f32/attachment.htm>