| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2026-03-11 | |||
| 15:06:53 | stephenfin | that should really happen in H: it's been 3 or 4 cycles now | |
| 15:06:56 | Uggla | stephenfin, i know :( | |
| 15:07:21 | sean-k-mooney | Uggla: ya it would be nice ot have at least a daft spec on that topic before the ptg if you intened to progress it but cool good to know | |
| 15:07:51 | sean-k-mooney | stephenfin: 2 it merged in 2025.1 | |
| 15:07:57 | sean-k-mooney | but yes it should | |
| 15:08:12 | stephenfin | 3 we won't get it done in G | |
| 15:08:15 | stephenfin | :) | |
| 15:08:44 | sean-k-mooney | i guess it depend on how you count be either way ya it shoudl be resolved if we expect to extend it in h | |
| 15:09:07 | sean-k-mooney | i woudl assum that horizon also does not have supprot for it | |
| 15:09:20 | Uggla | sean-k-mooney, stephenfin, my understanding is that it is an "internal" priority now, so that might help. | |
| 15:09:22 | sean-k-mooney | coudl be good to add to a cross project session | |
| 15:09:41 | opendevreview | Akira KAMIO proposed openstack/nova master: libvirt: support flavor disk/cdrom bus and SCSI model https://review.opendev.org/c/openstack/nova/+/980072 | |
| 15:09:46 | stephenfin | that would be my assumption. And I don't think Gophercloud does either so right now no one can use it using our clients | |
| 15:09:59 | stephenfin | except if they're using gtema's rust client, perhaps | |
| 15:21:11 | gmaan | Uggla: stephenfin we need to get this in before rc1, still stuck in gate https://review.opendev.org/c/openstack/nova/+/978494 | |
| 15:21:33 | sean-k-mooney | stephenfin: speaking of sdk/client supprot have you added suprpot for flavor seach by name | |
| 15:21:50 | sean-k-mooney | i.e. openstack flavor list --name ... | |
| 15:21:51 | stephenfin | oh, I thought that had merged already | |
| 15:21:59 | sean-k-mooney | it may have i just never checked | |
| 15:22:18 | sean-k-mooney | oh you mean ganshams link | |
| 15:22:58 | sean-k-mooney | that woudl quallify for rc2 anwyay and befcause fo the oder we do the rpc version pinning we alwasy? have one | |
| 15:23:01 | stephenfin | yeah. I haven't done the client changes yet | |
| 15:25:02 | sean-k-mooney | ok i should go back to testing things o/ | |
| 15:27:38 | stephenfin | sean-k-mooney: https://review.opendev.org/c/openstack/openstacksdk/+/980101 | |
| 15:28:58 | sean-k-mooney | do we need changes (seperatly) for 103 | |
| 15:29:05 | sean-k-mooney | to acoont for the rild cleanup | |
| 15:29:15 | opendevreview | Merged openstack/placement master: Update master for stable/2026.1 https://review.opendev.org/c/openstack/placement/+/980096 | |
| 15:29:28 | sean-k-mooney | maybe it woudl be good to have a list of these soemwhere | |
| 15:30:12 | opendevreview | Merged openstack/placement stable/2026.1: Update .gitreview for stable/2026.1 https://review.opendev.org/c/openstack/placement/+/980094 | |
| 15:32:53 | opendevreview | Merged openstack/placement stable/2026.1: Update TOX_CONSTRAINTS_FILE for stable/2026.1 https://review.opendev.org/c/openstack/placement/+/980095 | |
| 15:51:01 | gibi | Uggla: nothing on my radar that needed in rc1 | |
| 15:51:38 | gibi | but I see we are tracking a fix above | |
| 16:07:29 | opendevreview | Sylvain Bauza proposed openstack/nova master: Add functional tests for NUMA aware vswitches https://review.opendev.org/c/openstack/nova/+/979999 | |
| 16:34:56 | Uggla | gibi, yes gmaan's patch which does not want to land. :) | |
| 17:48:27 | opendevreview | Sylvain Bauza proposed openstack/nova master: Add functional tests for NUMA aware vswitches https://review.opendev.org/c/openstack/nova/+/979999 | |
| 20:37:06 | opendevreview | Merged openstack/nova stable/2025.2: Move cleanup of vTPM secret from driver to compute https://review.opendev.org/c/openstack/nova/+/979052 | |
| 21:28:34 | opendevreview | melanie witt proposed openstack/nova-specs master: Amend vTPM live migration spec https://review.opendev.org/c/openstack/nova-specs/+/980165 | |
| 21:28:35 | opendevreview | melanie witt proposed openstack/nova-specs master: Propose vTPM live migration: 'deployment' mode https://review.opendev.org/c/openstack/nova-specs/+/980166 | |
| 21:31:52 | opendevreview | melanie witt proposed openstack/nova-specs master: Propose vTPM live migration: 'deployment' mode https://review.opendev.org/c/openstack/nova-specs/+/980166 | |
| 21:34:03 | melwitt | Uggla: my lame attempt to split the spec ^ I kept the original blueprint url the same but updated the "title" to say 'host' mode. and I made a new blueprint for 'deployment' mode here https://blueprints.launchpad.net/nova/+spec/vtpm-live-migration-deployment-mode (which is linked in the new spec) | |
| 21:45:07 | opendevreview | Merged openstack/nova master: Fix wrong strict assertion of quota class set id https://review.opendev.org/c/openstack/nova/+/978494 | |
| #openstack-nova - 2026-03-12 | |||
| 00:09:04 | opendevreview | Ashish Gupta proposed openstack/nova master: Add native threading support to test case ID propagation fixtures https://review.opendev.org/c/openstack/nova/+/980179 | |
| 04:09:08 | seyeongkim | Do you think there’s a chance this patch could be merged into master, or does it need more work? https://review.opendev.org/c/openstack/nova/+/963665 Thanks! | |
| 05:22:36 | opendevreview | Nicolai Ruckel proposed openstack/nova stable/2025.1: Preserve vTPM state between power off and power on https://review.opendev.org/c/openstack/nova/+/979866 | |
| 07:10:38 | opendevreview | Ashish Gupta proposed openstack/nova master: Add native threading support to test case ID propagation fixtures https://review.opendev.org/c/openstack/nova/+/980179 | |
| 07:49:13 | Uggla | gmann, gibi, 978494: Fix wrong strict assertion of quota class set id | https://review.opendev.org/c/openstack/nova/+/9784gibi finally merged. What was just a matter of crossing fingers. :) | |
| 07:55:42 | Uggla | gibi, bauzas if you can review / +w 979008: Update compute rpc alias for Gazpacho | https://review.opendev.org/c/openstack/nova/+/979008, 979016: Add service version for Gazpacho | https://review.opendev.org/c/openstack/nova/+/979016 and 979023: Add Gazpacho prelude section | https://review.opendev.org/c/openstack/nova/+/979023 | |
| 07:56:59 | Uggla | gibi, bauzas, and this one too: 980165: Amend vTPM live migration spec | https://review.opendev.org/c/openstack/nova-specs/+/980165 | |
| 08:11:02 | bauzas | sure, I'll review those patches | |
| 08:11:06 | bauzas | (I'm used to :) ) | |
| 09:48:16 | bauzas | sean-k-mooney: fwiw, I started to peek at numa aware vswitches numa affinity problems and I created functests here for reproducing : https://review.opendev.org/c/openstack/nova/+/979999/ | |
| 09:48:59 | bauzas | at the moment, I'm not seeing any issue by the fixtures, as the scheduler provides limits to the compute claim | |
| 09:49:43 | bauzas | that's only when the filter doesn't pass the limits or if the reqspec is modified that we no longer get the limits for the claim and then the compute doesn't look at the numa nodes affinities | |
| 10:10:48 | opendevreview | Dominik proposed openstack/nova master: NUMA Topology with Resource Providers: Libvirt NUMA Migrate https://review.opendev.org/c/openstack/nova/+/971177 | |
| 11:51:30 | sean-k-mooney | bauzas: the probelm is not in the schduler | |
| 11:51:39 | sean-k-mooney | bauzas: so in the schduler it works its on the compute node | |
| 11:52:13 | sean-k-mooney | bauzas: when we reproduced it in a devstack enve we saw the schduelr do the right thing but when the compute agent called the same code it did not | |
| 11:53:03 | sean-k-mooney | bauzas: by the way the limits form the schdluer are not provided to the compute agenet | |
| 11:53:45 | sean-k-mooney | we reconsudct the instance numa toplogy blob in the compute and recompute the pining ectra we dont pass it over rpc today | |
| 11:54:14 | sean-k-mooney | bauzas: my guess its this si really dumb and we are just not passing a parmater somewhere | |
| 11:56:12 | sean-k-mooney | bauzas: as an asside if the numa shculder filter is not used numa is not suprpoted at all but but ti ssond liek you may have fount part of the issue network_metadata is missgin? | |
| 11:58:05 | sean-k-mooney | the compute agent shoudl enfoce numa regardelss fothe schduler config obvioulsy but the point im making is we have alwasy said useign numa feature without the schduler filter is not supprot upstream the compute agenet protections are just a saftey net so that you can evenutally fix your scdhluer config without needing ot move your vms | |
| 12:08:32 | opendevreview | Merged openstack/nova master: Add service version for Gazpacho https://review.opendev.org/c/openstack/nova/+/979016 | |
| 12:27:57 | opendevreview | Merged openstack/python-novaclient master: Add version foot protector https://review.opendev.org/c/openstack/python-novaclient/+/978254 | |
| 13:21:44 | bauzas | sean-k-mooney: I'd appreciate if you could look at my func reproducer patch https://review.opendev.org/c/openstack/nova/+/979999 | |
| 13:22:02 | bauzas | I agree with you on the fact the compute claim should do the same than the filter and doublecheck the network metadata | |
| 13:22:38 | bauzas | but I'm still wondering why those limits are not passed, because functests say "yes this is passed unless reschedules without alternativesé" | |
| 13:33:27 | sean-k-mooney | bauzas: the are not passed because we can race with tow diffent request | |
| 13:33:57 | sean-k-mooney | i.e. we cant safely use what the schduler has calulated without moving the instnace calim to the schduler | |
| 13:41:52 | sean-k-mooney | bauzas: the instnace claim buidl the numa constraits form teh falvor/image locally on teh comptue agent | |
| 13:42:16 | sean-k-mooney | my guess based on what you discsoced is we are not incuding the network metadtaa in that | |
| 14:09:26 | opendevreview | Takashi Natsume proposed openstack/nova master: Update contributor guide for 2026.1 Gazpacho https://review.opendev.org/c/openstack/nova/+/961896 | |
| 14:15:33 | opendevreview | Merged openstack/nova stable/2025.2: [nova-tox-py312-threading]Ignore failing tests https://review.opendev.org/c/openstack/nova/+/980013 | |
| 14:18:56 | nicolairuckel | Is the CI having a bad day today? There are random jobs failing for my changes. | |
| 14:22:04 | opendevreview | ribaudr proposed openstack/nova master: Add Gazpacho prelude section https://review.opendev.org/c/openstack/nova/+/979023 | |
| 14:22:15 | nicolairuckel | I had to rerun them because one of the gates failed (which was correct at that point) but one job was failing that ran before. So I rerun them again and now that one passed but another one fails. | |
| 14:22:26 | nicolairuckel | https://review.opendev.org/c/openstack/nova/+/978908 | |
| 14:24:12 | dansmith | sean-k-mooney: IIRC, the only way the whole admin/instance password thing works is either by injection in libvirt (disabled/discouraged) or via metadata.. cloud-init seems to not even support this, but cloudbase-init (for windows) does.. that line up with your understanding? | |
| 14:24:27 | dansmith | asking you because you're usually one of the more vocal anti-injection voices :) | |
| 14:24:43 | sean-k-mooney | dansmith: liek alwasy there is a third option | |
| 14:24:55 | sean-k-mooney | it can be set via the qemu guest agent without injection | |
| 14:25:15 | sean-k-mooney | but yes cloudbase init is the only thing that generates it on the compute startup and post teh value back via metadta | |
| 14:25:18 | dansmith | that's the set-password thing, I know that.. that's sort of different than what I'm asking | |
| 14:25:57 | sean-k-mooney | ya so your summery basicly matches my understanding | |
| 14:25:58 | dansmith | sean-k-mooney: libvirt will generate/store it in sysmeta I think, cloudbase-init can rewrite it IIRC | |
| 14:29:38 | dansmith | hmm, maybe it only does that during set.. so maybe I'm thinking of older rax/xen behavior.. you'd create an instance in horizon and immediately get back a "here's your admin password" dialog | |
| 14:29:39 | sean-k-mooney | dansmith: by the way i didnt think we saved the admin-password | |
| 14:30:01 | sean-k-mooney | i tought we only returned it on create/rebuild (encyprted via your keypair) | |
| 14:30:07 | sean-k-mooney | but that was only in memory | |
| 14:30:28 | sean-k-mooney | perhasp i imagined that | |
| 14:30:48 | dansmith | we store it in sysmeta in password_N keys | |
| 14:30:49 | sean-k-mooney | the reason i ask is i dont think its in server show | |
| 14:31:24 | dansmith | I thought it was in the create response but I'm not seeing where that would be now | |
| 14:31:28 | dansmith | it's not in server show | |
| 14:31:41 | sean-k-mooney | it is in the create respocne and in the rebuild responce | |
| 14:32:30 | sean-k-mooney | i assumed we did not have it in show because we did nto have it rather then not including it intentionally hence the question | |
| 14:32:59 | dansmith | I just don't see where it could be actually used during create I mean | |
| 14:33:00 | sean-k-mooney | i guess we must | |
| 14:33:02 | sean-k-mooney | https://docs.openstack.org/api-ref/compute/#show-server-password | |
| 14:33:16 | dansmith | I'll keep looking, not asking you for that, just if you knew of any other edges | |