| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2025-05-21 | |||
| 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 | |
| 18:45:57 | sean-k-mooney | i hope its not contoverial | |
| 18:46:15 | sean-k-mooney | there is at least some other interest form teh teleemtry folks to enabel this with cloud kitty | |
| 18:46:26 | sean-k-mooney | so that posivie | |
| 18:47:09 | Callum027 | Yeah, I'm sure they'd be interested since this improves the scalability of Ceilometer polling | |
| 18:47:58 | Callum027 | I can understand why people wouldn't be happy about it since this is basically putting lipstick on a pig, but anything more radical would require more fundamental design changes and I'm not sure I'm capable of championing that at this stage :) | |
| 18:49:14 | sean-k-mooney | well with my nova hat on it replaceing Ceilometer pooling the nova api with Ceilometer polling the libvirt api so if its a perfroamc eissue its not someone elses probelem. on the ohter had the domain xml is ment to be internal state | |
| 18:49:29 | sean-k-mooney | so if we just stop using them or libvirt changed ot yaml | |
| 18:49:47 | sean-k-mooney | that not a breakign change form a nova perspecitve as the xml is not public | |
| 18:49:55 | sean-k-mooney | but realisticlly that not going to happen | |
| 18:50:09 | sean-k-mooney | so as long as ceilometer is readonly its proably a net win | |
| 18:58:56 | Callum027 | I do think it's a relatively elegant solution to the scalability issues Ceiilometer faced, with the drawback that changes to the files require all instances to be shelved-and-unshelved to apply the changes (or updated in place using virsh commands) | |
| 18:59:34 | sean-k-mooney | no it just requries a hard reboot | |
| 19:00:04 | sean-k-mooney | the xml is regenerated on every hard reboot or start/power on call | |
| 19:00:10 | Callum027 | Oh, right, of course | |
| 19:00:31 | sean-k-mooney | shelve would work too but there are cheaper options | |
| 19:00:33 | Callum027 | I should update the release notes on those commits to mention that | |
| 19:00:50 | Callum027 | But the main thing is live migrating doesn't work since the XML gets copied over without modificaiton | |
| 19:01:02 | sean-k-mooney | it will also get added on a live migrate i think | |
| 19:01:16 | Callum027 | In our testing it didn't, but we're using an older version of Nova | |
| 19:01:17 | sean-k-mooney | or at least it would if you implemnted that in your code change | |
| 19:01:43 | sean-k-mooney | well no i mean nova can do that but you need to write the code | |
| 19:01:59 | Callum027 | Maybe part of "standardising" this would be that we write a more elegant way of updating the metadata of instances in place | |
| 19:02:08 | sean-k-mooney | https://github.com/openstack/nova/blob/master/nova/virt/libvirt/migration.py#L55-L97 | |
| 19:02:14 | Callum027 | For our production environment we wrote a one-off Ansible playbook to do it | |
| 19:02:28 | sean-k-mooney | i mean that fair too | |
| 19:02:37 | sean-k-mooney | although we dont like operators touching the xml | |
| 19:02:55 | Callum027 | Yeah, I definitely would have preferred to use the proper core for it | |
| 19:03:32 | sean-k-mooney | so perhaps as a follow up we could add updating of the metadata in the domain on live migrate | |
| 19:03:37 | sean-k-mooney | that not doen today in general | |
| 19:03:43 | sean-k-mooney | so its not really a bug in yoru patch | |
| 19:03:57 | sean-k-mooney | its just exsitng beahvior. cold migrate would pick up the chakge as weel | |
| 19:04:13 | Callum027 | Yeah, it's definitely a useful change though | |
| 19:04:39 | Callum027 | For now I've added the item to the agenda, I'll make sure I'm at the next meeting | |
| 19:04:58 | sean-k-mooney | ack | |
| 19:17:53 | opendevreview | sean mooney proposed openstack/nova master: move compile earlier https://review.opendev.org/c/openstack/nova/+/950516 | |
| #openstack-nova - 2025-05-22 | |||
| 01:10:35 | mikal | didn't in fact hallucinate the GPG signature requirement, are there minimum requirements for the GPG key used to sign the commit? My GPG key is relatively well connected, but also ancient. | |
| 01:10:35 | mikal | Potentially silly question(s), but is there a git plugin or precommit or whatever that will just make me magically DCO compliant with minimal effort? I am assuming that DCO implies GPG signed commits, although I cannot find a web page which clearly states tat -- it might just be some text in the commit message which alleges to come from me? If I | |
| 01:11:19 | mikal | Like... it would be cool if "git review" added missing DCO entries like it does missing change ids. | |
| 01:11:29 | opendevreview | Michael Still proposed openstack/nova master: Protect older compute managers from sound model requests. https://review.opendev.org/c/openstack/nova/+/940770 | |
| 01:11:29 | opendevreview | Michael Still proposed openstack/nova master: libvirt: Add extra spec for sound device. https://review.opendev.org/c/openstack/nova/+/926126 | |
| 01:11:30 | opendevreview | Michael Still proposed openstack/nova master: libvirt: Add extra specs for USB redirection. https://review.opendev.org/c/openstack/nova/+/927354 | |
| 04:57:34 | opendevreview | sean mooney proposed openstack/nova master: move compile earlier https://review.opendev.org/c/openstack/nova/+/950516 | |
| 04:57:35 | opendevreview | sean mooney proposed openstack/nova master: WIP : Add mtty support to nova-next https://review.opendev.org/c/openstack/nova/+/922140 | |
| 04:57:35 | opendevreview | sean mooney proposed openstack/nova master: Add mtty/mdpy support for testing fake mdevs https://review.opendev.org/c/openstack/nova/+/898100 | |
| 05:03:15 | sean-k-mooney | mikal: "git commit -s" should be all you need to do but im not sure yet about an automatic way yet. most seam to recomemd a git alis like "git config --global alias.cs commit --signoff" but `git commit -s` vs `git cs` does not help much | |
| 05:04:05 | sean-k-mooney | mikal: you do not need ot sign comites with DCO | |
| 05:04:24 | sean-k-mooney | you can but git now supprot using ssh keys instead of GPG keys for sgining if you want to do that | |
| 05:04:29 | mikal | Yeah, that bit confuses me. What's to stop a forgery of a signoff if its just a text string in the commit message? | |
| 05:04:48 | sean-k-mooney | https://dev.to/janderssonse/git-signoff-and-signing-like-a-champ-41f3 | |
| 05:05:41 | mikal | Ahhh, so signoff != signing. | |
| 05:05:42 | sean-k-mooney | mikal: well gerrit will prevent forgin the authero but the commit message can be updated | |
| 05:05:56 | sean-k-mooney | signing commtis wont help because we dont use mege commits | |
| 05:06:13 | sean-k-mooney | so your commit will be rebasees/cherry picked anyway when its merged by zuul | |
| 05:06:35 | mikal | Well, at least this means I can still stick with my 25 year old GPG key! | |
| 05:06:42 | mikal | Its an antique and needs to be cherished. | |
| 05:07:13 | sean-k-mooney | so i have gpg siging setup or at least id did before i reinstalled my laptop.... | |
| 05:07:41 | mikal | I GPG sign tags on some personal projects, although I am unclear on how meaningful that is with such an old key. | |