Open Stack

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)
> > 
> > 
>