| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2025-05-21 | |||
| 15:26:06 | dansmith | this is a just-rebuilt setup so let me test with the other aliases to make sure pci is working in general | |
| 15:28:16 | dansmith | hmm, no actually | |
| 15:28:55 | dansmith | I wonder if my pci filter is not getting set, hmm | |
| 15:29:33 | dansmith | ah, it's not | |
| 15:29:42 | dansmith | so that's probably why it worked before too, hrm | |
| 15:33:38 | dansmith | gibi: so, I had [scheduler] instead of [filter_scheduler] | |
| 15:33:40 | Uggla | dansmith, not sure but my pci_in_placement is in the filter_scheduler section. | |
| 15:33:51 | Uggla | :) | |
| 15:33:52 | dansmith | but, still works.. what all reads that? more than n-sch? | |
| 15:34:04 | dansmith | conductor maybe? | |
| 15:36:43 | gibi | if pci_in_placement is read by the api | |
| 15:36:49 | gibi | s/if// | |
| 15:37:04 | gibi | repot_in_placement is read by the compute | |
| 15:37:49 | gibi | (yes it is not optimal I know) | |
| 15:38:40 | dansmith | okay api is seeing the new value, still not stopping me | |
| 15:39:18 | gibi | I can try to reproduce the issue on my side... | |
| 15:39:41 | bauzas | what's the issue ? | |
| 15:40:13 | dansmith | but, even using a good alias isn't getting me the device or a failure, so something else must be broken. here | |
| 15:41:47 | Uggla | bauzas, my understanding is if you only specify an trait in the alias section, pci in placement should block that as it needs RC too. And it is not the case. | |
| 15:42:09 | bauzas | yeah, that could be the case | |
| 15:42:23 | bauzas | dansmith doesn't see anything in placement ? | |
| 15:42:33 | bauzas | about the PCI RPs | |
| 15:42:49 | bauzas | (just rebooted due to a wifi crash, <3 F42) | |
| 15:47:05 | dansmith | gibi: okay I had a typo in my flavor property so it was just being ignored. but, fixing that, here's what I see as a user: | |
| 15:47:06 | dansmith | https://paste.opendev.org/show/bI7lakvj0atefW6KPNkw/ | |
| 15:47:26 | dansmith | the log does have something in it, but it's not quite obvious I suspect | |
| 15:47:50 | dansmith | I suspect no operator will know what "resources={CUSTOM_PCI_NONE_NONE=1}" means | |
| 15:49:36 | gibi | yepp we need to add an explicit validation | |
| 15:49:50 | gibi | that either RC or product/vendor needs to be provided in the alias | |
| 15:50:13 | dansmith | yeah | |
| 15:51:07 | gibi | I can file a bug and link it to the downstream PCI in Placement Jira as well so we will have time for it to fix | |
| 15:51:08 | dansmith | gibi: so ... why again can we not support just the trait? You can ask for all providers with that trait, no? | |
| 15:51:30 | gibi | you cannot have an allocation candidate without telling placement what resource you are allocating | |
| 15:51:51 | dansmith | because you're asking for inventory not a provider? | |
| 15:52:09 | dansmith | (and providers have the traits) | |
| 15:52:40 | gibi | I'm asking for things I can allocate, I cannot allocate a trait or a provider I can only allocate a piece of inventory | |
| 15:53:06 | dansmith | right, that's what I mean | |
| 15:53:09 | gibi | yepp | |
| 15:54:13 | gibi | in our oversimplified case where a single PF RP only have a single RC with a single inventory allocation the RP or allocating one piece of that inventory is the same. | |
| 15:54:38 | gibi | so it is easy to make that mental jump that we want to allocate RPs | |
| 15:56:42 | gibi | this also shows the effect of the design decisions that we connect traits to RPs not to an inventory of the RP | |
| 15:57:05 | gibi | we allocate inventories but we filter on traits that are not on the inventories | |
| 15:57:20 | gibi | it is a bit of a mixup | |
| 15:57:35 | gibi | so we tend to namespace traits to somehow refer to inventories :) | |
| 15:58:04 | gibi | like with the OTU trait, we put PCI in the name to signify it is only related to PCI inventories of the RP | |
| 15:58:18 | gibi | anyhow | |
| 15:58:23 | gibi | I will going to file a bug | |
| 15:58:32 | gibi | based on your paste | |
| 16:01:42 | Uggla | gibi, yes but finally the code has blocked the invalid settings. So not so bad. | |
| 16:02:00 | gibi | https://bugs.launchpad.net/nova/+bug/2111440 | |
| 16:02:20 | gibi | Uggla: yep, but we should consider pre-validating the alias at sevice startup | |
| 16:02:30 | gibi | and also be a bit more instructive in the lgs | |
| 16:02:31 | gibi | logs | |
| 16:02:46 | dansmith | gibi: yeah there have been a few things in this journey where traits applied to providers to say something about inventory has been a bit weird | |
| 16:03:44 | dansmith | gibi: Uggla I also had a typo in my pci alias config (unparseable json) and it didn't get noticed until the first time I tried to boot with a pci-enabled flavor, and we returned json parse complaints to the user in the error :( | |
| 16:04:00 | dansmith | which of course is "line 1, character X" which makes no sense since they're all one line | |
| 16:04:11 | dansmith | would be much better if we can parse and log on startup which one is the problem | |
| 16:05:36 | gibi | filed the upstream bug and a matching downstream jira | |
| 16:07:49 | opendevreview | sean mooney proposed openstack/nova master: move compile earlier https://review.opendev.org/c/openstack/nova/+/950516 | |
| 16:11:46 | sean-k-mooney | dansmith: that a typo in the docs | |
| 16:12:30 | sean-k-mooney | when we added the docs for pci maged and live migration flags | |
| 16:12:47 | dansmith | what's a typo in the docs? | |
| 16:13:07 | sean-k-mooney | we missed it was not valid json. i hit the same thing when testin gthe OTU devices feature and pinged Uggla but i dont knwo if we filed an upstream bug or not to fix it | |
| 16:13:54 | sean-k-mooney | gibi: validiatign the config on start up is good we also shoudl be cachign it. | |
| 16:15:24 | sean-k-mooney | gibi: https://review.opendev.org/c/openstack/nova/+/427145 | |
| 16:16:22 | gibi | sean-k-mooney: good point, added the link to the bug | |
| 16:17:56 | sean-k-mooney | stephen didn twant the addtional complexity but going form 4062 function calls to 3 after caching is a masive savign | |
| 16:18:54 | sean-k-mooney | espically since we can just slap functools.cache on it now | |
| 16:20:06 | sean-k-mooney | from the blueprint """During the creation of an instance, a list of request is build. One of this requested elements are the PCI devices, both from the API call and from the flavor. | |
| 16:20:08 | sean-k-mooney | In the PCI request gathering from the flavor, the variable "pci_alias", stored in the Nova config file, is always parsed. This step is only needed once, because the information is static.""" | |
| 16:23:34 | sean-k-mooney | so every time we need to trasnlate a pci alise to to a pci request object we parst all the alisas again https://github.com/openstack/nova/blob/master/nova/pci/request.py#L124-L209 | |
| 16:24:43 | dansmith | Uggla: (cc gibi) FYI nvme emulation in qemu does work for testing this and is cleanable (via format only, not sanitize) | |
| 16:25:27 | Uggla | dansmith, cool ! | |
| 16:25:29 | dansmith | that device reports that it supports lots of namespaces (not sure if it really does, haven't tested yet) but that flags a warning I have queued for the script locally about multi-namespace devices being cleaned with format only (so that's a good test) | |
| 16:25:36 | sean-k-mooney | dansmith: the only issue wiht that iw while qemu can emulate it libvirt currently does nto supprot that so you have to use qemu directly unless i missed something in the xml for this ? | |
| 16:25:57 | dansmith | sean-k-mooney: right, you can configure it in the xml, but only via qemu:commandline | |
| 16:26:08 | gibi | cool. So we can use that for local testing. | |
| 16:26:12 | dansmith | so not helpful for people testing on top of an existing nova impl, unfortunately | |
| 16:26:17 | gibi | not in CI though | |
| 16:26:18 | dansmith | gibi: yeah | |
| 16:26:20 | sean-k-mooney | you can yes | |
| 16:26:20 | dansmith | right | |
| 16:27:02 | dansmith | gibi: it's also helpful so you can get a bunch of devices instead of just one (if you only have one) | |
| 16:27:14 | sean-k-mooney | i looked into that when we were reviwiong the spec but kind of gave up when i realed the gap in libvirt. you could just add the qemu args in virt manager to test it locally or just invoke qemu yourslef | |
| 16:28:44 | dansmith | https://termbin.com/tm0b | |
| 17:03:07 | sean-k-mooney | @gibi: the crd change is in merge conflict https://github.com/openstack-k8s-operators/nova-operator/pull/948 | |
| 17:03:24 | sean-k-mooney | gibi: im sure its trival but it will need to be rebased before it can merge | |
| 17:03:45 | sean-k-mooney | oh you already have | |
| 17:04:32 | sean-k-mooney | gibi: in that case ill add lgtm and assumign it passes ci it can proceed, does that work for you? | |
| 17:07:47 | gibi | yepp | |
| 17:07:54 | gibi | works for me | |
| 17:08:06 | gibi | (strange place to discuss it but fine :) | |
| 17:13:12 | sean-k-mooney | gibi: hehe wrong tab | |
| 17:52:48 | opendevreview | Dan Smith proposed openstack/nova master: Make example OTU cleaner support NVMe sanitize https://review.opendev.org/c/openstack/nova/+/950592 | |
| 18:42:55 | sean-k-mooney | gmaan: i didnt get as far as i hoped today but the first 10 patches in stephens sereise are still good to merge IMO i.e. https://review.opendev.org/c/openstack/nova/+/936365/8 -> https://review.opendev.org/c/openstack/nova/+/937048/11 | |
| 18:43:15 | sean-k-mooney | ill take a look at the next coupel of patches tomorrow | |
| 18:44:00 | gmaan | sean-k-mooney: ack, I will see if I can check those this week but next week I am planning. | |
| 18:44:50 | Callum027 | and hopefully get it merged for Flamingo. | |
| 18:44:50 | Callum027 | Hi sean-k-mooney, I added a comment to the change but I'd thought I'd let you know here as well - sorry for the inactivity on my changes, been a bit busy with work. We've deployed the changes to our production OpenStack environments and everything seems to be working great, so I'm happy to attend the next Nova meeting so we can discuss the proposal | |
| 18:45:48 | sean-k-mooney | Callum027: ack, if you cant just send a mail to the list asking for it to be approved | |