<div dir="auto"><div>Thanks for such detailed explanation, that makes sense indeed for me.<br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Jun 24, 2023, 00:58  <<a href="mailto:smooney@redhat.com">smooney@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Fri, 2023-06-23 at 17:08 +0200, Dmitriy Rabotyagov wrote:<br>
> I wonder what is the reason for such diversification between B and C then?<br>
the short version is nova maintains two version contants for libvirt/qemu version in <br>
our code base. our current minium and our future minium so in the b cycle we are updating<br>
our current minium to what was our planned future miniutm and we are decided what<br>
to set the next annouched future minium too.<br>
> As C will be the next SLURP [1] release, meaning A->C upgrades must be<br>
> supported. So doing a minimal version bump 2 times doesn't make too<br>
> much sense to me, as long as any platform we have in PTI is not<br>
> affected.<br>
> Also my assumption was that all version bumps (or deprecations)<br>
> ideally should happen during non-SLURP releases.<br>
there is actully no agreement on that specifically but if we were to adapt nova policy<br>
to the slurp release cycle we would want to ensure when we select a next min<br>
it is shiped in the release notes fo a SLUP release and then yes the actual bump would happen<br>
the non slurp or next sulrp release. The cadnace of when we actully do a min bump<br>
tend to be every 2-4 releases.<br>
> <br>
> So what's the reason not to do this now and wait for C?<br>
we cant with out breaking our policy of alwasy providing at least one release notice<br>
before increaing our min.<br>
<br>
the version bump we are doing for bobcat was ment to be done in zed and antelope <br>
but got pushed out for differnt reasosn. mainly gate instablity and review badnwith.<br>
<br>
we may or may not actully do a version bump in C but by advertising that our future min verions<br>
will move to that shiped in ubuntu 22.04. it means if we do decided to bump in C we will actully<br>
be testing with the min supported version. canonical assuming they hold to there normally pattern will be release<br>
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<br>
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<br>
by doing a second version bump in ci.<br>
<br>
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<br>
more modern again at that point.<br>
<br>
nova generally support quite a broad range of libvirt/qemu version so while it help reduce our tech debt when <br>
we increase our min version, in reality most distros end up shipping a much newer version then we technically support.<br>
<br>
> <br>
> [1] <a href="https://governance.openstack.org/tc/resolutions/20220210-release-cadence-adjustment.html" rel="noreferrer noreferrer" target="_blank">https://governance.openstack.org/tc/resolutions/20220210-release-cadence-adjustment.html</a><br>
> <br>
> пт, 23 июн. 2023 г. в 16:20, Thomas Goirand <<a href="mailto:zigo@debian.org" target="_blank" rel="noreferrer">zigo@debian.org</a>>:<br>
> > <br>
> > Hi,<br>
> > <br>
> > Repeating what I wrote on IRC.<br>
> > <br>
> > On 6/23/23 16:10, Kashyap Chamarthy wrote:<br>
> > >    - Debian 11 (Bullseye):<br>
> > >      - libvirt: 7.0.0-3+deb11u2<br>
> > >      - qemu: 5.2+dfsg-11+deb11u2<br>
> > <br>
> > As far as Debian is concerned, the last version of OpenStack supported<br>
> > on Bullseye was Zed (like every 4 OpenStack release and for each new<br>
> > Debian release, there's a version of Zed that I maintain for both<br>
> > Bullseye and Bookworm, to offer easier transitions). Everything above<br>
> > that, needs to run on bookworm. I will *not* do any backport for Debian<br>
> > 11, which is already the past for me. In this case, for Debian 12 (aka:<br>
> > Bookworm) we have:<br>
> > <br>
> >     - Debian 11 (Bullseye):<br>
> >       - libvirt: 9.0.0<br>
> >       - qemu: 7.2<br>
> > <br>
> > So feel free to bump up to that. If needed, I can even do backports<br>
> > myself for these key components, whenever they reach Testing. Probably<br>
> > soon libvirt 9.4.0 (which is already in Experimental, and that will<br>
> > probably soon reach Unstable, then testing).<br>
> > <br>
> > I hope this helps,<br>
> > Cheers,<br>
> > <br>
> > Thomas Goirand (zigo)<br>
> > <br>
> > <br>
> <br>
<br>
</blockquote></div></div></div>