Earlier  
Posted Nick Remark
#openstack-nova - 2026-07-13
08:29:18 bauzas we did created m1, m2 and m3 before :)
08:29:28 bauzas like 10 years before
08:29:35 gibi yeah but not in the last couple of years
08:29:51 gibi but it seems the release tooling correctly chose b1 if I ask for a hibiscus milestone release
08:29:56 gibi so all seems good
08:30:19 elodilles :]
08:30:38 bauzas lovely
08:31:17 bauzas gibi: given Uggla is on PTO, please ping me the release change and I'll +1
08:33:11 gibi https://review.opendev.org/c/openstack/releases/+/996992
08:33:54 gibi bauzas: elodilles: ^^ please take a look
08:35:27 elodilles gibi: LGTM, just need a Verified+1 and a release-liaison CR+1 o:)
08:35:47 gibi bauzas will do that :)
08:37:34 elodilles :]
08:38:06 opendevreview Balazs Gibizer proposed openstack/nova master: Check service_ref before destroy https://review.opendev.org/c/openstack/nova/+/996793
08:38:06 opendevreview Balazs Gibizer proposed openstack/nova master: Speed up functional test in threading mode https://review.opendev.org/c/openstack/nova/+/996500
08:38:30 gibi this is two small stability / performance fixes for the functional test in threading mode
08:38:49 gibi if somebody want to look :)
08:38:52 opendevreview Takashi Kajinami proposed openstack/nova master: Update documentations for AMD SEV-SNP support https://review.opendev.org/c/openstack/nova/+/995090
08:39:02 bauzas gibi: I can take a look
08:39:08 opendevreview Takashi Kajinami proposed openstack/nova master: Remove [libvirt] num_memory_encrypted_guests https://review.opendev.org/c/openstack/nova/+/995120
08:39:14 opendevreview Takashi Kajinami proposed openstack/nova master: Use domain capabilities to detect SEV-SNP support https://review.opendev.org/c/openstack/nova/+/996316
08:40:00 gibi this is more involved https://review.opendev.org/q/topic:%22bug/2160224%22 but also needed evetually for the functional test as it is failing intermittently due to this race
08:44:31 bauzas gibi: ok let's merge the two ones first then
08:44:45 gibi sure
08:44:50 gibi thanks
08:45:06 gibi I got gmaan looking at the 3rd one as that is a slight API change
08:49:39 sean-k-mooney[m] gibi: sorry hadnat actully started yet. i though placement like now was release-with-intermediary not release-with-rc
08:50:49 sean-k-mooney[m] i didnt think we had any proejct that were not https://releases.openstack.org/reference/release_models.html#cycle-with-intermediary as part of the upstream compute team
08:54:24 gibi sean-k-mooney[m]: no worries. the release tooling allowed me to push 16.0.0b1 for placement and it seem the release team is OK with it
08:54:34 sean-k-mooney[m] i feel like that got incrrectly change in the release repo at some poitn
08:54:45 sean-k-mooney[m] well to me this is a bigger problem then that
08:55:38 sean-k-mooney[m] when we moved from cycle-with-milestones i tought we moved to cycle-with-intermediary
08:56:35 sean-k-mooney[m] cycle-with-rc project should not have release at milestone 1 or 2 like we have been doing for nova
08:57:22 sean-k-mooney[m] hum or maybe we havnt done that for nova
08:58:21 gibi i need to defer to the release team :)
08:58:24 sean-k-mooney[m] hum i see
08:58:31 sean-k-mooney[m] elease-model: cycle-with-intermediary is there for os-vif
08:58:39 bauzas sean-k-mooney[m]: I can't remember where we do set the cycle models for each of the repos but I'm pretty sure placement is cycle-with-rc
08:58:40 sean-k-mooney[m] and we are usign that for our libs
08:58:50 sean-k-mooney[m] but we have cycle-with-rc for the service projects
08:59:13 bauzas some of our libs are cycle-with-intermediary and some are independent yes
08:59:38 bauzas I was thinking the cycle model was defined in https://opendev.org/openstack/governance/src/branch/master/reference/projects.yaml but alas no
08:59:50 sean-k-mooney[m] its set in 2 places, you can spcify it in the grovernace repo but tis also in the release repo in the deliverabvle
09:00:22 sean-k-mooney[m] bauzas: it can be yes we dont have it set which means its coming form a default adn or cofniguration in the release repo
09:00:38 bauzas found the definition
09:01:38 bauzas https://opendev.org/openstack/releases/src/branch/master/deliverables/hibiscus/placement.yaml
09:01:49 sean-k-mooney[m] where? the inline release-model: in the deliverable is set form somewhere else
09:01:54 bauzas that's why the release tool accepted b1 for placement
09:02:13 sean-k-mooney[m] that is genereate by the tool automaticly each cycle
09:02:27 sean-k-mooney[m] when we create the first deliberable for that release
09:02:51 bauzas ,o
09:02:52 bauzas no
09:02:54 sean-k-mooney[m] but where is the data for that coming form i tought it was coming form the governace repo
09:03:09 bauzas you can use the tool for generating optional milestone releases
09:03:20 bauzas please look at what we discussed just before
09:03:41 bauzas https://opendev.org/openstack/releases/src/branch/master/deliverables/hibiscus/os-vif.yaml os-vif is indeed cycle-with-intermediary
09:03:45 sean-k-mooney[m] i knwo you can your not answering my question
09:03:49 bauzas and os-traits is independent
09:04:12 bauzas are you asking me how the tool works ? I don't know
09:04:22 sean-k-mooney[m] the release model in the delverable file is set form somethign else or a human ahas been seting it for every proejct for every release and we have not been doing that
09:04:28 sean-k-mooney[m] i am not
09:04:42 bauzas are you asking who defines that model ? that's humans
09:04:45 sean-k-mooney[m] i am telling you that i know about the release-model in the release repo
09:04:49 bauzas that's us
09:04:58 sean-k-mooney[m] no
09:05:03 sean-k-mooney[m] i am not askign that either
09:05:46 sean-k-mooney[m] i am saying the release-model in the release repo is set form somewhere else, or a human has been seting it by hand for every new release for every project
09:05:50 sean-k-mooney[m] i dont think its the latter
09:06:16 bauzas sec
09:06:20 bauzas https://opendev.org/openstack/releases/commit/eb4b8e535ba9ab9c53ad65dd98f2a0eb980c436e
09:06:25 bauzas my internet is slow
09:06:42 bauzas but that's done by the releases team at the beginning of the cycle
09:06:56 bauzas unless a project wants to change the release model
09:07:27 sean-k-mooney[m] so they are just copying the model form the previous release or are they pulling form somewhere else
09:07:39 bauzas that's written in the commit message :)
09:07:49 bauzas or ask elodilles :)
09:08:41 sean-k-mooney[m] ok the reason im askign is we agreed to change some of these back in zed/antelope during the ptg specififcly for the python-novaclient
09:08:49 sean-k-mooney[m] so that it would move to the indepentend mode
09:08:52 sean-k-mooney[m] and it was never done
09:09:19 sean-k-mooney[m] but i tough twe move nova almost all our project away form cycle-with-rc to cycle-with-intermediary
09:09:33 sean-k-mooney[m] anyway its fine
09:10:48 bauzas https://releases.openstack.org/reference/using.html#helpers I even bet elodilles runs "tox -evenv -- new-release init_series" command :)
09:11:03 sean-k-mooney[m] https://etherpad.opendev.org/p/nova-antelope-ptg#L449
09:11:13 elodilles bauzas: is right
09:11:22 elodilles i mean bauzas is right o:)
09:11:26 bauzas the release mgmt team does great work with documenting what they do and their tools they use :)
09:11:45 bauzas elodilles: only because you guys do great job with documenting all you do
09:11:48 elodilles so the command is just copies over the deliverables details, as is
09:12:23 sean-k-mooney[m] ya its more a case fo we are not grate at going in and updating the metadata when we change how we work wiht things
09:12:33 sean-k-mooney[m] like reconfiguring placment to not list storyborad
09:14:09 sean-k-mooney[m] we move that back to launchpad when it was taken back under the nova umbrella years ago
09:15:06 elodilles sean-k-mooney[m]: about changing release model: independent release model has its disadvantage as not having stable branches, which means there is no possibility to do stable releases, which is painful for example in case python version supports are dropped in the meanwhile, etc.
09:15:54 sean-k-mooney[m] elodilles: well for python-novaclient we have frozen the shell and pyhton binding
09:16:16 sean-k-mooney[m] so we were not ment to have new release each cycle in general
09:16:40 sean-k-mooney[m] we already have feature partity in osc and we only support new microverions in the sdk
09:17:51 elodilles sean-k-mooney[m]: in theory it is OK, but i'm sure there would be a point when an 'urgent stable release' would be needed o:) (been there with oslo ;))
09:18:17 elodilles sorry, i need to go AFK for a while now
09:18:23 sean-k-mooney[m] perhas although it will hopefully get returied in the next couple of release
09:18:34 sean-k-mooney[m] elodilles: no worries o/
09:47:07 opendevreview Artem Vasilyev proposed openstack/nova master: Fix race between resize and update_available_resource for dedicated CPUs https://review.opendev.org/c/openstack/nova/+/984048

Earlier   Later