| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2026-07-13 | |||
| 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 | |
| 09:47:25 | opendevreview | Artem Vasilyev proposed openstack/nova master: Add reproducer for bug #2147776 https://review.opendev.org/c/openstack/nova/+/984007 | |
| 11:30:43 | opendevreview | Bhavana proposed openstack/nova master: Add custom GPU PCI weigher for scheduler optimization Add Minimal Displacement Solver for MIG GPU Repartitioning https://review.opendev.org/c/openstack/nova/+/996058 | |
| 11:49:55 | tkajinam | could anyone review and merge https://review.opendev.org/c/openstack/nova/+/996880 ? | |
| 11:50:05 | tkajinam | ^^^ doc update after migration of cursive to oslo's namespace | |
| 12:11:03 | gibi | sean-k-mooney[m]: bauzas: ( elodilles): 16.0.0b1 placement is released and our tox targest are using it as they are asking for >= 9.0.0b1 and that triggers beta version usage in pip | |
| 12:11:29 | bauzas | ? | |
| 12:11:56 | gibi | bauzas: just YI so that the placement release went out and it works in our test env without further version bump | |
| 12:12:09 | bauzas | ah ok | |
| 12:12:15 | bauzas | so no issue | |
| 12:12:18 | gibi | no issue | |
| 12:13:56 | sean-k-mooney | gibi: what did we actully need that for by the way i missed that this morning | |
| 12:14:09 | sean-k-mooney | was it for the change to the fuctional fixture | |
| 12:14:20 | sean-k-mooney | to allow the db to use files | |
| 12:14:31 | sean-k-mooney | to unblock threaded mode ? | |
| 12:14:47 | gibi | yes it was fixture change on the placement side to be able to pass connection URL for the DB fixture in placement | |
| 12:14:53 | sean-k-mooney | ack | |
| 12:15:45 | sean-k-mooney | tox-sibling woudl have enabeld required-project to use master or any pinned checkout but unless we wanted to do that permently | |
| 12:15:49 | sean-k-mooney | doing the release is cleaner | |
| 12:16:05 | sean-k-mooney | the factg we dont use tox-siblings is why depend on only works for devstack today | |
| 12:16:20 | gibi | I did not find an example of tox-siblings and release was faster :) | |
| 12:16:24 | elodilles | sean-k-mooney[m]: is it possible that this patch needs to be backported to all stable branches? https://review.opendev.org/c/openstack/devstack-plugin-ceph/+/955714 | |
| 12:17:08 | elodilles | sean-k-mooney[m]: as this test case is failing on nova's stable/2025.1 nova-ceph-multistore job: https://review.opendev.org/c/openstack/nova/+/995958 | |
| 12:17:14 | sean-k-mooney | no it can be but its not required | |
| 12:17:23 | elodilles | (tempest is branchless) | |
| 12:17:36 | sean-k-mooney | there is a better change to backport i think | |
| 12:17:56 | sean-k-mooney | well so we have a "fix" for nova | |
| 12:18:04 | sean-k-mooney | backporting that may be better | |
| 12:18:39 | sean-k-mooney | the fix is adding a config option for current hardcode value so in addtion to that we woudl ahve to tweak the job to set that | |
| 12:19:10 | sean-k-mooney | elodilles: https://review.opendev.org/c/openstack/nova/+/969538 | |
| 12:19:15 | sean-k-mooney | so if we backport that | |
| 12:19:40 | sean-k-mooney | oh mel set the defautl to 2 | |
| 12:19:42 | sean-k-mooney | images_address_space_limit | |
| 12:19:52 | sean-k-mooney | so that should jsut work | |
| 12:20:06 | sean-k-mooney | sicne she alrady doubled the hardcoded value for the new config default | |
| 12:20:38 | opendevreview | sean mooney proposed openstack/nova stable/2026.1: Make QEMU_IMG_LIMITS process limits configurable https://review.opendev.org/c/openstack/nova/+/997027 | |
| 12:22:51 | opendevreview | sean mooney proposed openstack/nova stable/2025.2: Make QEMU_IMG_LIMITS process limits configurable https://review.opendev.org/c/openstack/nova/+/997028 | |
| 12:23:14 | opendevreview | sean mooney proposed openstack/nova stable/2025.1: Make QEMU_IMG_LIMITS process limits configurable https://review.opendev.org/c/openstack/nova/+/997029 | |
| 12:23:24 | sean-k-mooney | elodilles: so ^ in theory should work | |
| 12:23:39 | elodilles | sean-k-mooney: so to be clear, this patch is needed to make this test case stable: test_extend_attached_encrypted_volume_luksv1 | |
| 12:23:42 | elodilles | right? | |
| 12:24:35 | sean-k-mooney | yes | |
| 12:24:59 | elodilles | ACK, sorry, i'm a bit slow today double checking things o:) | |
| 12:25:07 | sean-k-mooney | the luks hearder make 1g cinder voluem need more the 1G of aresss space for qemu img to map and or process them | |
| 12:25:33 | sean-k-mooney | the patch set the default for the new config option to 2g | |
| 12:25:39 | elodilles | though i'm not really fond of changing config value on stable branches only to make test cases pass :/ | |
| 12:26:11 | sean-k-mooney | well the other option is no luks on ubuntu 24.04 | |
| 12:26:26 | sean-k-mooney | because without the patch its hardcoded to 1 | |
| 12:26:47 | elodilles | yes, that's what i'm saying o:) | |
| 12:26:55 | elodilles | s/what/why | |
| 12:27:10 | sean-k-mooney | so this was really cause by a chagne in qemu | |
| 12:27:33 | sean-k-mooney | and how qemu-img internally manges its concurancy | |
| 12:27:52 | elodilles | so we need 2G to make the test pass, but that changes the value for already deployed environments from 1G to 2G if i understand correctly | |
| 12:27:55 | sean-k-mooney | the current change mimics what cinder and ironic do | |
| 12:28:38 | sean-k-mooney | elodilles: so i think the real long tim fix is to remove the adress space based limit and move to RSS (resedet set size) or drop the limit entrily | |
| 12:29:08 | sean-k-mooney | it exits to prvent patalogical behvior in qemu-img form triggerign the OOM killer | |
| 12:30:13 | elodilles | i see | |
| 12:30:50 | sean-k-mooney | which form a defence in dept pont of view i get but adressspace was never the right thing to limit on in my view RSS was but even then we dont sandbox all the other clis we interact with so it feels kind of arbiaty that we did limit qemu-img | |
| 12:33:28 | elodilles | sean-k-mooney: still, i'm a bit hesitant to backport this patch. i'd perhaps tempest-regex-exclude for this single test case on stable branches (as this test case was disabled before the revert has landed on tempest) | |
| 12:34:09 | sean-k-mooney | well this test used to be sable on the stable branchs | |
| 12:34:20 | sean-k-mooney | it was broken by a qemu release | |
| 12:34:51 | sean-k-mooney | so sure we can disbale it but i think we expect to backport the bugfix regardless fo the ci | |
| 12:35:14 | sean-k-mooney | this sued to work on stable and it was regressed by a ubuntu package release | |
| 12:35:23 | elodilles | ah, i see | |
| 12:35:25 | sean-k-mooney | so we want to be abel to suprpot existing users | |
| 12:37:12 | sean-k-mooney | elodilles: this affect a very specific subset of deployemtn because it depens on teh qemu+librados/ceph clinet release in use. and you have to have encypted volumes as well. | |
| 12:37:37 | sean-k-mooney | anyway lets get some ci results adn see if the backprot even works | |
| 12:38:43 | sean-k-mooney | elodilles: we could also backport swaping the ceph jobs to debian 12 but chaning the disto seams more invasive to me | |
| 12:39:07 | sean-k-mooney | althouhg it would only be on 2025.1 | |
| 12:39:25 | sean-k-mooney | 2025.2+ already were using debian for ceph | |
| 12:40:52 | sean-k-mooney | elodilles: https://review.opendev.org/c/openstack/devstack-plugin-ceph/+/997035 we can proably dicusss that in the qa channel seperatly | |
| 12:44:00 | elodilles | sean-k-mooney: thanks for the explanation. i've commented on the patch my concern o:) | |
| 12:45:47 | sean-k-mooney | we could set it to the same value in the backport and tweak it in the job or as you said just exclude the test form the relevent jobs | |
| 12:48:36 | elodilles | i'm not fully against backporting the patch as is, if stable cores agree to do so o:) but maybe the above options are less invasive ^^^ | |