| opendevreview | yaguang proposed openstack/nova master: libvirt: enable Hyper-V evmcs on Intel VMX hosts https://review.opendev.org/c/openstack/nova/+/995620 | 03:19 |
|---|---|---|
| opendevreview | Bhavana proposed openstack/nova master: Add Minimal Displacement Solver for MIG GPU Repartitioning https://review.opendev.org/c/openstack/nova/+/996058 | 06:37 |
| opendevreview | Bhavana proposed openstack/nova master: Add Minimal Displacement Solver for MIG GPU Repartitioning https://review.opendev.org/c/openstack/nova/+/996058 | 06:42 |
| *** ykarel_ is now known as ykarel | 07:20 | |
| gibi | sean-k-mooney[m] gmaan: I think we need to tweak the functional-py313-threading job as it pulls placement from pypi but we needed to land a fix in placement master that is not release yet. | 08:16 |
| gibi | https://zuul.opendev.org/t/openstack/build/fdefa3b20f4f471cb6f0ef9b29ccd241/log/job-output.txt#870 | 08:16 |
| *** mhen_ is now known as mhen | 08:17 | |
| sean-k-mooney[m] | We can use tox siblings and required projects I think to pull master | 08:18 |
| sean-k-mooney[m] | Or we can just release placement | 08:18 |
| gibi | I assuem that zuul's required-projects only work with devstack based jobs not tox based ones | 08:24 |
| bauzas | gibi: good call | 08:24 |
| gibi | I'm trying to find an example of tox siblings | 08:24 |
| bauzas | we can do a placement release indeed | 08:24 |
| bauzas | that looks to me the simpliest | 08:24 |
| gibi | can we release from master randomly even if placement is expected to be release at milestones? | 08:24 |
| gibi | elodilles: ^^ cc | 08:25 |
| bauzas | gibi: we can do a rc2 | 08:25 |
| bauzas | lemme check the release cycle | 08:25 |
| gibi | we are not in an rc period | 08:25 |
| bauzas | we can do milestones | 08:25 |
| gibi | M2 is in a week or se | 08:25 |
| gibi | so | 08:25 |
| bauzas | oh sorry, I meant milestone-2 | 08:25 |
| gibi | can we do an M2 early/ | 08:26 |
| gibi | ? | 08:26 |
| bauzas | yes | 08:26 |
| bauzas | or any milestone | 08:26 |
| bauzas | sec | 08:26 |
| bauzas | https://releases.openstack.org/reference/release_models.html#cycle-with-rc | 08:26 |
| gibi | OK, if we can that is indeed the cheapest | 08:26 |
| bauzas | "The “cycle-with-rc” model describes projects that produce a single release at the end of the cycle, with one or more release candidates (RC) close to the end of the cycle and optional development milestone betas published on a per-project need." | 08:27 |
| bauzas | we can create any optional milestone release if we wantr | 08:27 |
| gibi | ^^ that means to me that we need to push an rc1 now | 08:27 |
| bauzas | no | 08:27 |
| gibi | that description does not talk about milestone releaes | 08:27 |
| bauzas | we will need to publish a rc1 | 08:27 |
| elodilles | gibi: yes we can release a 16.0.0.0b1 or 0b2 release anytime | 08:27 |
| gibi | OK | 08:27 |
| bauzas | that ^ | 08:27 |
| gibi | I will propose a b1 now | 08:28 |
| gibi | thanks | 08:28 |
| bauzas | we have to create a RC1 at least, yes | 08:28 |
| elodilles | not many project do that, but some do release beta releases (milestone releases) | 08:28 |
| bauzas | but as elodilles said, we can create *any* milestone releases | 08:29 |
| elodilles | just merged a couple of neutron related beta release patches in the morning ;) | 08:29 |
| bauzas | we did created m1, m2 and m3 before :) | 08:29 |
| bauzas | like 10 years before | 08:29 |
| gibi | yeah but not in the last couple of years | 08:29 |
| gibi | but it seems the release tooling correctly chose b1 if I ask for a hibiscus milestone release | 08:29 |
| gibi | so all seems good | 08:29 |
| elodilles | :] | 08:30 |
| bauzas | lovely | 08:30 |
| bauzas | gibi: given Uggla is on PTO, please ping me the release change and I'll +1 | 08:31 |
| gibi | https://review.opendev.org/c/openstack/releases/+/996992 | 08:33 |
| gibi | bauzas: elodilles: ^^ please take a look | 08:33 |
| elodilles | gibi: LGTM, just need a Verified+1 and a release-liaison CR+1 o:) | 08:35 |
| gibi | bauzas will do that :) | 08:35 |
| elodilles | :] | 08:37 |
| opendevreview | Balazs Gibizer proposed openstack/nova master: Speed up functional test in threading mode https://review.opendev.org/c/openstack/nova/+/996500 | 08:38 |
| opendevreview | Balazs Gibizer proposed openstack/nova master: Check service_ref before destroy https://review.opendev.org/c/openstack/nova/+/996793 | 08:38 |
| gibi | this is two small stability / performance fixes for the functional test in threading mode | 08:38 |
| gibi | if somebody want to look :) | 08:38 |
| opendevreview | Takashi Kajinami proposed openstack/nova master: Update documentations for AMD SEV-SNP support https://review.opendev.org/c/openstack/nova/+/995090 | 08:38 |
| bauzas | gibi: I can take a look | 08:39 |
| opendevreview | Takashi Kajinami proposed openstack/nova master: Remove [libvirt] num_memory_encrypted_guests https://review.opendev.org/c/openstack/nova/+/995120 | 08:39 |
| opendevreview | Takashi Kajinami proposed openstack/nova master: Use domain capabilities to detect SEV-SNP support https://review.opendev.org/c/openstack/nova/+/996316 | 08:39 |
| 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:40 |
| bauzas | gibi: ok let's merge the two ones first then | 08:44 |
| gibi | sure | 08:44 |
| gibi | thanks | 08:44 |
| gibi | I got gmaan looking at the 3rd one as that is a slight API change | 08:45 |
| sean-k-mooney[m] | gibi: sorry hadnat actully started yet. i though placement like now was release-with-intermediary not release-with-rc | 08: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:50 |
| 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 |
| sean-k-mooney[m] | i feel like that got incrrectly change in the release repo at some poitn | 08:54 |
| sean-k-mooney[m] | well to me this is a bigger problem then that | 08:54 |
| sean-k-mooney[m] | when we moved from cycle-with-milestones i tought we moved to cycle-with-intermediary | 08:55 |
| 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:56 |
| sean-k-mooney[m] | hum or maybe we havnt done that for nova | 08:57 |
| gibi | i need to defer to the release team :) | 08:58 |
| sean-k-mooney[m] | hum i see | 08:58 |
| sean-k-mooney[m] | elease-model: cycle-with-intermediary is there for os-vif | 08:58 |
| 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 |
| sean-k-mooney[m] | and we are usign that for our libs | 08:58 |
| sean-k-mooney[m] | but we have cycle-with-rc for the service projects | 08:58 |
| bauzas | some of our libs are cycle-with-intermediary and some are independent yes | 08:59 |
| 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 |
| 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 | 08:59 |
| 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 |
| bauzas | found the definition | 09:00 |
| bauzas | https://opendev.org/openstack/releases/src/branch/master/deliverables/hibiscus/placement.yaml | 09:01 |
| sean-k-mooney[m] | where? the inline release-model: in the deliverable is set form somewhere else | 09:01 |
| bauzas | that's why the release tool accepted b1 for placement | 09:01 |
| sean-k-mooney[m] | that is genereate by the tool automaticly each cycle | 09:02 |
| sean-k-mooney[m] | when we create the first deliberable for that release | 09:02 |
| bauzas | ,o | 09:02 |
| bauzas | no | 09:02 |
| sean-k-mooney[m] | but where is the data for that coming form i tought it was coming form the governace repo | 09:02 |
| bauzas | you can use the tool for generating optional milestone releases | 09:03 |
| bauzas | please look at what we discussed just before | 09:03 |
| bauzas | https://opendev.org/openstack/releases/src/branch/master/deliverables/hibiscus/os-vif.yaml os-vif is indeed cycle-with-intermediary | 09:03 |
| sean-k-mooney[m] | i knwo you can your not answering my question | 09:03 |
| bauzas | and os-traits is independent | 09:03 |
| bauzas | are you asking me how the tool works ? I don't know | 09:04 |
| 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 |
| sean-k-mooney[m] | i am not | 09:04 |
| bauzas | are you asking who defines that model ? that's humans | 09:04 |
| sean-k-mooney[m] | i am telling you that i know about the release-model in the release repo | 09:04 |
| bauzas | that's us | 09:04 |
| sean-k-mooney[m] | no | 09:04 |
| sean-k-mooney[m] | i am not askign that either | 09:05 |
| 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 |
| sean-k-mooney[m] | i dont think its the latter | 09:05 |
| bauzas | sec | 09:06 |
| bauzas | https://opendev.org/openstack/releases/commit/eb4b8e535ba9ab9c53ad65dd98f2a0eb980c436e | 09:06 |
| bauzas | my internet is slow | 09:06 |
| bauzas | but that's done by the releases team at the beginning of the cycle | 09:06 |
| bauzas | unless a project wants to change the release model | 09:06 |
| sean-k-mooney[m] | so they are just copying the model form the previous release or are they pulling form somewhere else | 09:07 |
| bauzas | that's written in the commit message :) | 09:07 |
| bauzas | or ask elodilles :) | 09:07 |
| 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 |
| sean-k-mooney[m] | so that it would move to the indepentend mode | 09:08 |
| sean-k-mooney[m] | and it was never done | 09:08 |
| 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 |
| sean-k-mooney[m] | anyway its fine | 09:09 |
| bauzas | https://releases.openstack.org/reference/using.html#helpers I even bet elodilles runs "tox -evenv -- new-release init_series" command :) | 09:10 |
| sean-k-mooney[m] | https://etherpad.opendev.org/p/nova-antelope-ptg#L449 | 09:11 |
| elodilles | bauzas: is right | 09:11 |
| elodilles | i mean bauzas is right o:) | 09:11 |
| bauzas | the release mgmt team does great work with documenting what they do and their tools they use :) | 09:11 |
| bauzas | elodilles: only because you guys do great job with documenting all you do | 09:11 |
| elodilles | so the command is just copies over the deliverables details, as is | 09:11 |
| 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 |
| sean-k-mooney[m] | like reconfiguring placment to not list storyborad | 09:12 |
| sean-k-mooney[m] | we move that back to launchpad when it was taken back under the nova umbrella years ago | 09:14 |
| 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 |
| sean-k-mooney[m] | elodilles: well for python-novaclient we have frozen the shell and pyhton binding | 09:15 |
| sean-k-mooney[m] | so we were not ment to have new release each cycle in general | 09:16 |
| sean-k-mooney[m] | we already have feature partity in osc and we only support new microverions in the sdk | 09:16 |
| 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:17 |
| elodilles | sorry, i need to go AFK for a while now | 09:18 |
| sean-k-mooney[m] | perhas although it will hopefully get returied in the next couple of release | 09:18 |
| sean-k-mooney[m] | elodilles: no worries o/ | 09:18 |
| 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 |
| opendevreview | Artem Vasilyev proposed openstack/nova master: Add reproducer for bug #2147776 https://review.opendev.org/c/openstack/nova/+/984007 | 09:47 |
| *** zseguin is now known as Guest13301 | 10:20 | |
| 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:30 |
| tkajinam | could anyone review and merge https://review.opendev.org/c/openstack/nova/+/996880 ? | 11:49 |
| tkajinam | ^^^ doc update after migration of cursive to oslo's namespace | 11:50 |
| 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 |
| bauzas | ? | 12:11 |
| gibi | bauzas: just YI so that the placement release went out and it works in our test env without further version bump | 12:11 |
| bauzas | ah ok | 12:12 |
| bauzas | so no issue | 12:12 |
| gibi | no issue | 12:12 |
| sean-k-mooney | gibi: what did we actully need that for by the way i missed that this morning | 12:13 |
| sean-k-mooney | was it for the change to the fuctional fixture | 12:14 |
| sean-k-mooney | to allow the db to use files | 12:14 |
| sean-k-mooney | to unblock threaded mode ? | 12:14 |
| 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 |
| sean-k-mooney | ack | 12:14 |
| 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 |
| sean-k-mooney | doing the release is cleaner | 12:15 |
| sean-k-mooney | the factg we dont use tox-siblings is why depend on only works for devstack today | 12:16 |
| gibi | I did not find an example of tox-siblings and release was faster :) | 12:16 |
| 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:16 |
| 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 |
| sean-k-mooney | no it can be but its not required | 12:17 |
| elodilles | (tempest is branchless) | 12:17 |
| sean-k-mooney | there is a better change to backport i think | 12:17 |
| sean-k-mooney | well so we have a "fix" for nova | 12:17 |
| sean-k-mooney | backporting that may be better | 12:18 |
| 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:18 |
| sean-k-mooney | elodilles: https://review.opendev.org/c/openstack/nova/+/969538 | 12:19 |
| sean-k-mooney | so if we backport that | 12:19 |
| sean-k-mooney | oh mel set the defautl to 2 | 12:19 |
| sean-k-mooney | images_address_space_limit | 12:19 |
| sean-k-mooney | so that should jsut work | 12:19 |
| sean-k-mooney | sicne she alrady doubled the hardcoded value for the new config default | 12:20 |
| 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:20 |
| 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:22 |
| 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 |
| sean-k-mooney | elodilles: so ^ in theory should work | 12:23 |
| 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 |
| elodilles | right? | 12:23 |
| sean-k-mooney | yes | 12:24 |
| elodilles | ACK, sorry, i'm a bit slow today double checking things o:) | 12:24 |
| 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 |
| sean-k-mooney | the patch set the default for the new config option to 2g | 12:25 |
| elodilles | though i'm not really fond of changing config value on stable branches only to make test cases pass :/ | 12:25 |
| sean-k-mooney | well the other option is no luks on ubuntu 24.04 | 12:26 |
| sean-k-mooney | because without the patch its hardcoded to 1 | 12:26 |
| elodilles | yes, that's what i'm saying o:) | 12:26 |
| elodilles | s/what/why | 12:26 |
| sean-k-mooney | so this was really cause by a chagne in qemu | 12:27 |
| sean-k-mooney | and how qemu-img internally manges its concurancy | 12:27 |
| 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 |
| sean-k-mooney | the current change mimics what cinder and ironic do | 12:27 |
| 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:28 |
| sean-k-mooney | it exits to prvent patalogical behvior in qemu-img form triggerign the OOM killer | 12:29 |
| elodilles | i see | 12:30 |
| 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:30 |
| 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:33 |
| sean-k-mooney | well this test used to be sable on the stable branchs | 12:34 |
| sean-k-mooney | it was broken by a qemu release | 12:34 |
| sean-k-mooney | so sure we can disbale it but i think we expect to backport the bugfix regardless fo the ci | 12:34 |
| sean-k-mooney | this sued to work on stable and it was regressed by a ubuntu package release | 12:35 |
| elodilles | ah, i see | 12:35 |
| sean-k-mooney | so we want to be abel to suprpot existing users | 12:35 |
| 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 |
| sean-k-mooney | anyway lets get some ci results adn see if the backprot even works | 12:37 |
| 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:38 |
| sean-k-mooney | althouhg it would only be on 2025.1 | 12:39 |
| sean-k-mooney | 2025.2+ already were using debian for ceph | 12:39 |
| 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:40 |
| elodilles | sean-k-mooney: thanks for the explanation. i've commented on the patch my concern o:) | 12:44 |
| 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:45 |
| 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 ^^^ | 12:48 |
| opendevreview | Joan Gilabert proposed openstack/nova master: Add libvirt driver MDEV ARQ support for Cyborg https://review.opendev.org/c/openstack/nova/+/995840 | 13:12 |
| opendevreview | Merged openstack/nova master: doc: Update cursive repository path https://review.opendev.org/c/openstack/nova/+/996880 | 13:33 |
| gmaan | gibi: thanks for placement release, I had to do same workaround of testing nova cross jobs with placement master when enforce_scope removal caused the issue. I tired to release it but then dropped the idea to let it releases during its own time. | 15:27 |
| gmaan | gibi: on 2160224, I will check today bug and the change. | 15:27 |
| opendevreview | Joan Gilabert proposed openstack/nova master: Report OWNER_NOVA trait on resource providers https://review.opendev.org/c/openstack/nova/+/994299 | 15:35 |
| opendevreview | Joan Gilabert proposed openstack/nova master: Add libvirt driver MDEV ARQ support for Cyborg https://review.opendev.org/c/openstack/nova/+/995840 | 15:35 |
| gibi | gmaan: thanks! | 15:35 |
| gibi | it turned out that releasing a beta was easy | 15:36 |
| gibi | FYI nova meeting starts in 20 mintes here. (I will be your guide today) | 15:39 |
| gibi | #startmeeting nova | 16:00 |
| opendevmeet | Meeting started Mon Jul 13 16:00:49 2026 UTC and is due to finish in 60 minutes. The chair is gibi. Information about MeetBot at http://wiki.debian.org/MeetBot. | 16:00 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 16:00 |
| opendevmeet | The meeting name has been set to 'nova' | 16:00 |
| gibi | o/ | 16:00 |
| tkajinam | o/ | 16:01 |
| elodilles | o/ | 16:01 |
| gibi | lets wait a bit to see if others show up | 16:02 |
| gibi | I know that Uggla and bauzas are off today | 16:02 |
| gibi | #topic Bugs (stuck/critical) | 16:03 |
| gibi | any bugs to talk about? | 16:03 |
| gibi | #topic Gate status | 16:04 |
| gibi | anything worth mentioning about the gate? | 16:04 |
| tkajinam | nothing I'm aware of, though we might need to be careful about gate status for a while after mass m-2 releases of libraries | 16:04 |
| gibi | good heads up | 16:04 |
| tkajinam | removal of enforce_scope is one of the upcoming big changes. | 16:05 |
| gibi | we also landed major functional test changes to support threading, the threading job is non voting at the moment and hopefully the change does not affect the eventlet job | 16:05 |
| gibi | but if you see strange things in functional test then let me know | 16:06 |
| elodilles | oh, btw, there was a cross-nova job failure in oslo.concurrency release | 16:06 |
| sean-k-mooney | o/ | 16:06 |
| gibi | elodilles: do you have a link? | 16:06 |
| elodilles | this is the patch: https://review.opendev.org/c/openstack/requirements/+/996809 | 16:06 |
| elodilles | and this is the job: https://zuul.opendev.org/t/openstack/build/9c3d2302c2dc453092804e0db538deb3 | 16:06 |
| elodilles | i've already pinged the oslo team | 16:07 |
| elodilles | on IRC | 16:07 |
| gibi | the failing test called test_concurrent_server_delete so I feel relavance here :) | 16:07 |
| sean-k-mooney | hum | 16:07 |
| elodilles | just popped into my mind now that tkajinam mentioned the mass m-2 releases o:) | 16:07 |
| gibi | anyhow I can take a deper look tomorrow | 16:07 |
| tkajinam | I wasn't aware of any functional changes we recently merged into oslo.concurrecy so that looks a bit strange | 16:08 |
| tkajinam | ping me in case you need hands from oslo side (and I'm aware of some discussions about slow futurist between gibi and sean-k-mooney but am not following it fully) | 16:08 |
| sean-k-mooney | that test hevially depens on lock machanics | 16:08 |
| gibi | tkajinam: thanks. | 16:08 |
| gibi | anyhow moving on, we can handle that async | 16:09 |
| gibi | #topic Release Planning | 16:09 |
| tkajinam | yup | 16:09 |
| gibi | so other than the m-2 lib releases anything else about the release schedule? | 16:09 |
| elodilles | nothing else from me | 16:10 |
| gibi | #topic Review priorities | 16:10 |
| gibi | any important patch is stuck? | 16:10 |
| gibi | #topic Stable Branches | 16:11 |
| gibi | elodilles, your turn | 16:11 |
| elodilles | thanks o/ | 16:11 |
| elodilles | so | 16:11 |
| elodilles | #info placement stable/2025.1 is blocked - workaround: https://review.opendev.org/c/openstack/placement/+/992299 | 16:11 |
| elodilles | #info nova stable/2025.1 branch is unstable due to nova-ceph-multistore job | 16:11 |
| elodilles | this is new now ^^^ :/ | 16:12 |
| elodilles | see details here: | 16:12 |
| elodilles | #info stable branch status / gate failures tracking etherpad: https://etherpad.opendev.org/p/nova-stable-branch-ci | 16:12 |
| elodilles | there is a bug fix backport from sean-k-mooney | 16:12 |
| elodilles | and i've commented on it | 16:12 |
| elodilles | need nova stable core's opinion about the way forward | 16:13 |
| sean-k-mooney | it passed on 2025.1 by the way but there are 3 paths forward | 16:13 |
| elodilles | yepp | 16:13 |
| elodilles | and that's all from me | 16:13 |
| elodilles | back to you gibi | 16:13 |
| sean-k-mooney | just a short tldr, we can backport melwitt's adress space confituraiton patch | 16:14 |
| gibi | https://review.opendev.org/q/topic:%22bug/2116852%22 | 16:14 |
| gibi | this one I assume | 16:14 |
| sean-k-mooney | we can change stablle 2025.1 ceph jobs to use debian 12 | 16:14 |
| sean-k-mooney | or we can tweak the regex | 16:14 |
| sean-k-mooney | and if we do backprot then we have a chocie of the defautl config value | 16:15 |
| sean-k-mooney | but yes | 16:15 |
| sean-k-mooney | its that bug | 16:15 |
| gibi | OK | 16:15 |
| fwiesel | o/ | 16:15 |
| melwitt | why not let 1G be default on stable and tweak the job for stable to use 2G? that would seem more standard to me as to what real life operator would do | 16:15 |
| gibi | so I see elodilles had some backportability concrens and sean-k-mooney replied | 16:15 |
| sean-k-mooney | i dont really ahve a stong opion on what approch we take | 16:15 |
| elodilles | melwitt: that's another good option, imo, too | 16:15 |
| sean-k-mooney | i just create the backport to confirm they actully work | 16:15 |
| gibi | I'm fine with melwitt's proposal if that helps accepting the backport on stalbe | 16:16 |
| gibi | stable | 16:16 |
| melwitt | yes thanks for doing that sean-k-mooney | 16:16 |
| elodilles | +1 | 16:16 |
| melwitt | (I'm replying on gerrit also) | 16:16 |
| gibi | cool | 16:16 |
| gibi | I think we can continue this on the review | 16:16 |
| melwitt | ++ | 16:16 |
| sean-k-mooney | mechaniclaly would you like me to update them or will melwitt do it | 16:16 |
| elodilles | +1 | 16:16 |
| sean-k-mooney | but ya we can move on | 16:16 |
| sean-k-mooney | we can decied that after the meeting | 16:17 |
| gibi | OK | 16:17 |
| gibi | any other stable business? | 16:17 |
| gibi | #topic vmwareapi 3rd-party CI efforts Highlights | 16:18 |
| gibi | fwiesel: any news? | 16:18 |
| fwiesel | Added some gating as changes in tempest and devstack caused some regressions. | 16:18 |
| fwiesel | But we are still not back to the old working state. | 16:18 |
| fwiesel | Still Debugging what else needs to get fixed. | 16:19 |
| fwiesel | That's from my side | 16:19 |
| gibi | thanks. do you need help? | 16:19 |
| fwiesel | gibi: thanks, but I'm fine | 16:19 |
| gibi | cool | 16:20 |
| gibi | #topic Kamil's news about eventlet removal | 16:20 |
| gibi | I'm filling in | 16:20 |
| gibi | so we landed the functional test changes to support threading mode | 16:20 |
| gibi | the job is still non voting. we have couple of follow ups to stabilize and speed it up | 16:20 |
| gibi | then we will make it voting | 16:20 |
| gmaan | ++ | 16:21 |
| gibi | but the tox -e functional-py313-threading target is already usable if needed | 16:21 |
| gibi | there are two patches that is reviewable https://review.opendev.org/c/openstack/nova/+/996793 | 16:22 |
| gibi | (and ^^ its parent) | 16:22 |
| gmaan | will check today | 16:23 |
| gibi | Kamil started working on futurist enhancements on Executors to support some of our advanced use cases. This might need coordianation with sean-k-mooney effort of fixing the slow shutdown bug in futurist | 16:23 |
| sean-k-mooney | ack, i did a bunch of general performacne improment in followups | 16:23 |
| gibi | sean-k-mooney: I'm aware and I will take a look at them during the week | 16:24 |
| sean-k-mooney | in comparison to the stdlib thread pool futurists is slow | 16:24 |
| sean-k-mooney | and the dynamic one has some pathalogicl behvior with small short lived tasks | 16:24 |
| gibi | Kamil's work https://review.opendev.org/c/openstack/futurist/+/975508 Sean's work https://review.opendev.org/c/openstack/futurist/+/975508 | 16:24 |
| sean-k-mooney | im goign to bring the 2 bugfixes to the front and leave the larger effincy feature to the end of my work | 16:25 |
| gmaan | sean-k-mooney: this series? #link https://review.opendev.org/c/openstack/futurist/+/996817/1 | 16:25 |
| gmaan | can you add a single topic/hashtag, I will add those in my list | 16:25 |
| sean-k-mooney | https://review.opendev.org/c/openstack/futurist/+/996574/1 | 16:25 |
| sean-k-mooney | that was the end of the serise | 16:25 |
| sean-k-mooney | gmaan: ya i can git-reivew nolonger does that by default | 16:26 |
| gibi | sean-k-mooney: make sense pulling the bugfixes in front, thanks | 16:26 |
| gibi | that is my eventlet update. Anything else on eventlet? | 16:26 |
| gmaan | but can you add somewere which one is must for bug fixes and others are improvement? | 16:26 |
| sean-k-mooney | gmaan: yep ill do that when i clean up the seriese | 16:26 |
| tkajinam | I guess https://review.opendev.org/c/openstack/futurist/+/996568 is must-have | 16:26 |
| gmaan | thanks | 16:26 |
| tkajinam | seeing the closes-bug tag | 16:26 |
| sean-k-mooney | https://review.opendev.org/c/openstack/futurist/+/996574/1/tools/threadpool_executor_benchmark_report.md is not intened to be meged but its ased on the testing i was doing | 16:27 |
| tkajinam | and its parent is reproducer | 16:27 |
| gibi | tkajinam: yepp | 16:27 |
| sean-k-mooney | tkajinam: ya i need to file a second bug for the second isseu i found | 16:27 |
| gmaan | because that will be needed/helpful for graceful shutdown also | 16:27 |
| sean-k-mooney | and ill add the relevent metadta in the commits | 16:27 |
| gibi | awesome | 16:27 |
| tkajinam | sounds good | 16:28 |
| gibi | moving on | 16:28 |
| gibi | #topic Nova using openstack sdk for neutron | 16:28 |
| gibi | I think Lajos is off this week | 16:28 |
| sean-k-mooney | https://review.opendev.org/c/openstack/futurist/+/996573/1 is the second bugfix by the way | 16:28 |
| sean-k-mooney | anyway moving on | 16:28 |
| gibi | anybody has any update on the SDKifying work? | 16:29 |
| elodilles | nope | 16:29 |
| sean-k-mooney | i have not looked at it in about 2 weeks | 16:29 |
| gibi | OK moving on then | 16:29 |
| gibi | #topic Ironic review priorities | 16:29 |
| gibi | anything stuck with ironic? | 16:29 |
| sean-k-mooney | https://review.opendev.org/q/topic:%22startup-time%22 could be worth looking at :) | 16:30 |
| gibi | I made some review there and will contineu | 16:31 |
| sean-k-mooney | thanks | 16:31 |
| sean-k-mooney | the first 4 patches are the important ones | 16:31 |
| gibi | OK | 16:31 |
| sean-k-mooney | the simulator and docs are useful but not strictly needed | 16:31 |
| gibi | #topic Confidential computing, status of SNP and TDX features | 16:32 |
| gibi | tkajinam: antia: any news? | 16:32 |
| tkajinam | based on the agreement about the way to detect SNP support in host, I've updated the whole implementation chain. | 16:33 |
| tkajinam | the agreement is being captured in this spec update https://review.opendev.org/c/openstack/nova-specs/+/996394 | 16:33 |
| gibi | ohh I need to jump on that spec update as well. thanks for the reminder. | 16:34 |
| gibi | I looked that the SNP series today and I'm happy with it | 16:34 |
| tkajinam | I think we are concluding the implementation so any final feedback is welcome. I saw Hiroki also voted his +1 so I believe he is agreeing with the direction, too (though I'm struggling to catch up with him honestly) | 16:35 |
| gibi | tkajinam: good call | 16:35 |
| gibi | I don't see antia on IRC today and the intel TDX series not moved yet | 16:36 |
| tkajinam | yeah | 16:36 |
| gibi | so I'm getting a bit worried about progress there | 16:36 |
| gibi | I will try to reach out to antia during the week | 16:37 |
| gibi | anything else about confidential computing features? | 16:37 |
| tkajinam | nothing else from my end | 16:38 |
| gibi | I skip bug scrubbing as I have no new data since last week | 16:38 |
| gibi | #link https://etherpad.opendev.org/p/nova-bug-triage-roster | 16:38 |
| gibi | #link https://truc.uggla.fr/ | 16:38 |
| gibi | these links should have up to date stats and work assignment | 16:38 |
| gibi | #topic Open discussion | 16:39 |
| gibi | Uggla is off for 3 weeks. bauzas will drive the next two IRC meetings | 16:39 |
| gibi | any other topic to cover today? | 16:39 |
| tkajinam | quick one | 16:41 |
| gibi | antia: Hi! lets quickly get back to you. Is there any news on the intel TDX series? | 16:41 |
| antia | Hi! Sorry for being late. Nothing mayor, had quite the busy downstream week but made some progress on parts of the series | 16:42 |
| gibi | antia: feel free to push even a half working stuff so that we can start giving guidance | 16:42 |
| antia | One problem I faced was when rebasing the patches and uploading to Gerrit | 16:42 |
| antia | Is it normal to have the changes be pushed to the other series as well? | 16:43 |
| sean-k-mooney | it depends on your local git tree | 16:43 |
| gibi | antia: you can place your stuff on other people's changes just be careful not to change their commits | 16:43 |
| antia | so as long as the commits remain unchanged it should be fine? | 16:44 |
| sean-k-mooney | when you do that its best to do "git review -R" | 16:44 |
| gibi | antia: yes | 16:44 |
| sean-k-mooney | yes although normlalyits best to work off master when possible unless your cordianting with the other person | 16:44 |
| sean-k-mooney | we stack changes if they have a natual depency | 16:45 |
| gibi | sean-k-mooney: here we coordinating as the two series are in conflict | 16:45 |
| sean-k-mooney | ack | 16:45 |
| gibi | touching the same enum, etc | 16:45 |
| antia | then it looks correctly, Gerrit just gives a scary warning :) | 16:45 |
| gibi | antia: what warning? :) | 16:45 |
| tkajinam | I guess it warns multiple commits are being proposed | 16:46 |
| antia | yes exactly | 16:47 |
| tkajinam | nothing (except for topic, which we can fix easily) should be changed unless you edit the existing commits | 16:47 |
| tkajinam | or we could even revert the series back to the previous patch sets | 16:47 |
| gibi | antia: double check that the hash the last commit from tkajinam in your local tree is the same as the latest from gerrit. I.e. to see if tkajinam pushed a new version of his patch in the meantime | 16:48 |
| antia | Yes will do that before uploading | 16:49 |
| gibi | if you are unsure then just drop the git log --oneline output to some 18:42 < antia> Hi! Sorry for being late. Nothing mayor, had quite the busy downstream week but made some progress on parts of the series | 16:49 |
| gibi | sorry | 16:49 |
| gibi | wrong copy-paste buffer | 16:49 |
| gibi | so git log --oneline output to https://paste.openstack.org/ and we can help | 16:50 |
| gibi | anyhow running out of time and tkajinam had another topic | 16:50 |
| gibi | tkajinam: go ahead | 16:50 |
| tkajinam | https://review.opendev.org/c/openstack/nova/+/995620 | 16:51 |
| tkajinam | I happened to find that in review queue and was involved in its review. it seems we likely need a new image prop. | 16:51 |
| gibi | is this a new feature? | 16:52 |
| tkajinam | I'm wondering which process should we follow now.(spec or specless bp) | 16:52 |
| gibi | we are late for either at this point | 16:52 |
| tkajinam | the new image prop to enable a new hyper-v enlightenment feature | 16:52 |
| tkajinam | yeah I thought so, but just wanted to hear opinion from others for double-check | 16:52 |
| tkajinam | ok I'll leave such comment in review. thanks (I'm unsure if the onwer is in irc) | 16:53 |
| gibi | I think it might qualify for specless in Indri but we have to wait | 16:53 |
| gibi | anything else before we close the meeting? | 16:54 |
| tkajinam | nothing else from me ! | 16:54 |
| * gibi wanted a quick summer meeting but filled the hour, sorry | 16:54 | |
| gibi | #endmeeting | 16:55 |
| opendevmeet | Meeting ended Mon Jul 13 16:55:01 2026 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 16:55 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/nova/2026/nova.2026-07-13-16.00.html | 16:55 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/nova/2026/nova.2026-07-13-16.00.txt | 16:55 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/nova/2026/nova.2026-07-13-16.00.log.html | 16:55 |
| gibi | thanks folks | 16:55 |
| gibi | antia: we can continue | 16:55 |
| elodilles | thanks too o/ | 16:55 |
| tkajinam | thanks ! | 16:55 |
| antia | gibi: here is gitlog and gerrit warning https://paste.openstack.org/show/b3hGRYq7qtxpuY2DRUpk/ | 16:59 |
| sean-k-mooney | gibi: tkajinam so speaking of conflict im inclinet too say since i need to rebase my change anyway lets just land https://review.opendev.org/c/openstack/nova/+/994342 | 16:59 |
| sean-k-mooney | so im going to go review that properly now with that in mind | 16:59 |
| sean-k-mooney | well | 16:59 |
| sean-k-mooney | im still not sure about the new is_supported_mem_encryption_model fucntion and if its ok to remvoe that again | 17:00 |
| tkajinam | checking | 17:01 |
| sean-k-mooney | antia: so if you did "git review -R" that disables rebasing in git review | 17:02 |
| gibi | eb455009ac this is an old version of tkajinam's series | 17:02 |
| sean-k-mooney | antia: so provided you didnt already rebase the inital commits in the series they wont be updated | 17:02 |
| antia | I need to update this based on the changes | 17:03 |
| gibi | (in pure git without git review, this means pulling the ps 13 from https://review.opendev.org/c/openstack/nova/+/994764 and rebasing your commit on top) | 17:03 |
| tkajinam | sean-k-mooney, hmm a problem is that memory encryption support is not in driver capabilities yet. we could add it but that'd be removed later once start up check is delegated to drivers. | 17:04 |
| antia | yes I rebased in pure git before so it is just about rebasing with the new ps | 17:05 |
| tkajinam | sean-k-mooney, are you ok if I propose a follow-up to add that capability ? though I'd abandon that once your validation delegation is merged. | 17:05 |
| sean-k-mooney | adding and removing a cpablity is cheaper then a dirver function | 17:06 |
| sean-k-mooney | but once we add and remove either i think and dont do a release in between we are sort of ok | 17:06 |
| sean-k-mooney | there wont have been a release for any one to depend on it | 17:07 |
| sean-k-mooney | so no need for deprecation of your new methond | 17:07 |
| sean-k-mooney | i just want to make sure other agree that i can jsut delete is as part fo the refactor | 17:07 |
| gibi | antia: yepp one more rebase :) | 17:15 |
| antia | I think it is clear then :) | 17:16 |
| antia | I'll ask again if I run into something else | 17:16 |
| gibi | antia: sure | 17:18 |
| tkajinam | https://zuul.opendev.org/t/openstack/builds?job_name=nova-alt-configurations&project=openstack/nova | 17:36 |
| tkajinam | it seems nova-alt-configurations POST_FAILURE is now broken now due to missing cinder service | 17:37 |
| tkajinam | https://bugs.launchpad.net/python-openstackclient/+bug/2160553 | 17:42 |
| melwitt | OSC server create requires cinder? that seems ... wrong | 17:45 |
| tkajinam | yeah | 17:47 |
| tkajinam | I roughly suspect it is an regression caused by https://review.opendev.org/c/openstack/python-openstackclient/+/994996 | 17:48 |
| opendevreview | Takashi Kajinami proposed openstack/nova master: DNM: Testing https://review.opendev.org/c/openstack/nova/+/997104 | 17:54 |
| tkajinam | https://review.opendev.org/c/openstack/python-openstackclient/+/996626 | 17:55 |
| tkajinam | oh slawek already proposed a fix | 17:55 |
| melwitt | ahh nice | 17:56 |
| opendevreview | sean mooney proposed openstack/nova stable/2026.1: Make QEMU_IMG_LIMITS process limits configurable https://review.opendev.org/c/openstack/nova/+/997027 | 18:03 |
| sean-k-mooney | melwitt: elodilles if that work for you ill update the rest | 18:03 |
| sean-k-mooney | although ill probly to the rest tomorrow | 18:03 |
| sean-k-mooney | so no rush | 18:03 |
| melwitt | cool thanks sean-k-mooney, will review | 18:05 |
| opendevreview | Merged openstack/nova master: Speed up functional test in threading mode https://review.opendev.org/c/openstack/nova/+/996500 | 18:31 |
| opendevreview | sean mooney proposed openstack/nova master: Delegate startup instance processing to drivers https://review.opendev.org/c/openstack/nova/+/990552 | 20:05 |
| opendevreview | sean mooney proposed openstack/nova master: Add vTPM startup validation reproducer https://review.opendev.org/c/openstack/nova/+/990551 | 20:07 |
| opendevreview | sean mooney proposed openstack/nova master: Delegate startup instance processing to drivers https://review.opendev.org/c/openstack/nova/+/990552 | 20:07 |
| opendevreview | sean mooney proposed openstack/nova master: Reduce ProviderTree copy cost for Ironic https://review.opendev.org/c/openstack/nova/+/980676 | 20:07 |
| opendevreview | sean mooney proposed openstack/nova master: Parallelize per-node resource updates https://review.opendev.org/c/openstack/nova/+/980679 | 20:08 |
| opendevreview | sean mooney proposed openstack/nova master: perf: add ironic startup performance simulator https://review.opendev.org/c/openstack/nova/+/980641 | 20:08 |
| opendevreview | sean mooney proposed openstack/nova master: docs: add Ironic startup performance measurements https://review.opendev.org/c/openstack/nova/+/980680 | 20:09 |
| JayF | dansmith: if you get an extra moment; https://review.opendev.org/c/openstack/ironic/+/997105 is the corollary fix in Ironic for OSSN-0101 if you wanna take a look. Just wanted to let you know since you authored the Nova one. | 20:25 |
| gmaan | gibi: sean-k-mooney: thanks for the more details in bug and I am good on the attachment_id 404 case and it does not need microverison. The only use case I was thinking was if user monitoring it to know if the attachment is ready but that is not valid or guranteed case. So returning attachment_id=None is not actually a success case even return code is 200. -1 on that change only for the test cases | 22:51 |
| gmaan | https://review.opendev.org/c/openstack/nova/+/996757 | 22:51 |
| opendevreview | Ghanshyam Maan proposed openstack/nova master: Add doc and release notes for the graceful shutdown task tracking https://review.opendev.org/c/openstack/nova/+/997141 | 23:01 |
| opendevreview | KWAK JOONGKEE proposed openstack/nova master: policy: initialize enforcer before publishing it https://review.opendev.org/c/openstack/nova/+/997142 | 23:34 |
Generated by irclog2html.py 4.1.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!