| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2025-05-27 | |||
| 16:17:41 | Uggla | fyi I have just asked for the Cloud hypervisor, to have the first patches. As we discussed last week. | |
| 16:18:31 | Uggla | but tbh I have not looked closely yet to know if we progressed. | |
| 16:18:54 | Uggla | #topic OpenAPI | |
| 16:19:04 | Uggla | #link: https://review.opendev.org/q/topic:%22openapi%22+(project:openstack/nova+OR+project:openstack/placement)+-status:merged+-status:abandoned | |
| 16:19:20 | Uggla | 22 patches remaining. (+1) | |
| 16:19:36 | Uggla | #topic Stable Branches | |
| 16:19:50 | Uggla | elodilles, your turn. | |
| 16:20:07 | elodilles | thanks, i'll be short, as there's nothing to report | |
| 16:20:10 | elodilles | #info stable branches (stable/2025.1 and stable/2024.*) seem to be in OK state | |
| 16:20:16 | elodilles | Uggla: back to you | |
| 16:20:24 | Uggla | cool thx elodilles | |
| 16:20:39 | Uggla | #topic vmwareapi 3rd-party CI efforts Highlights | |
| 16:20:56 | Uggla | fwiesel, something to share ? | |
| 16:21:20 | fwiesel | So, from my side I want to introduce dpascual. He will be my stand-in, in case I should be inable to attend. | |
| 16:21:36 | Uggla | dpascual, welcome | |
| 16:21:37 | dpascual | hi everyone | |
| 16:22:01 | fwiesel | He is operating the vmwareapi CI, and hopefully should keep you in the loop in case I can't | |
| 16:22:51 | fwiesel | Otherwise, since last Tuesday, we have a problem with some change in neutron. I am debugging this, so the CI failures come from there. | |
| 16:22:58 | fwiesel | That's from my side. | |
| 16:23:09 | fwiesel | Uggla: back to you | |
| 16:23:41 | Uggla | fwiesel, thx good to know. | |
| 16:24:26 | Uggla | #topic Gibi's news about eventlet removal. | |
| 16:24:31 | Uggla | #link Series: https://gibizer.github.io/categories/eventlet/ | |
| 16:24:51 | Uggla | #link nova-scheduler series is ready for core review, starting at https://review.opendev.org/c/openstack/nova/+/947966 | |
| 16:24:52 | gibi | no new blogpost as my prios mostly elsewhere these weeks | |
| 16:25:10 | gibi | sean-k-mooney gave some review and I respin the series to fix them | |
| 16:25:37 | gibi | oslo.service threading backend released and the global req bumped so we are now using the official oslo.service version in the series | |
| 16:25:48 | gibi | that is all | |
| 16:25:52 | Uggla | \o/ | |
| 16:26:11 | Uggla | thx gibi | |
| 16:26:20 | Uggla | #topic Open discussion | |
| 16:26:30 | Uggla | #link Callum027: Spec-less blueprint for adding new attributes to libvirt domain XML metadata: https://blueprints.launchpad.net/nova/+spec/xml-image-meta | |
| 16:26:49 | Callum027 | Hi guys, I am proposing a spec-less blueprint to add new metadata to Nova's libvirt domain metadata for Ceilometer and other telemetry-related OpenStack services. | |
| 16:26:52 | Uggla | Hi Callum027 | |
| 16:27:05 | Callum027 | it and has done for a long time, and changing this at this point would be a big project. | |
| 16:27:05 | Callum027 | To give some context, a long time ago Ceilometer used to perform API queries for polling instances. Because this was not scalable it was changed to reading the XML metadata Nova adds to the libvirt domain metadata on hypervisors. My understanding is that this was not the original intention for how this metadata is used, but Ceilometer now relies on | |
| 16:27:22 | Callum027 | metadata to not only make it unnecessary for Ceilometer to make API queries for compute polling in most cases, but also add additional metadata that make it easier to use services like CloudKitty to implement OpenStack billing. | |
| 16:27:22 | Callum027 | The problem that Ceilometer faces is that this metadata does not provide enough information for Ceilometer to do what it needs, so Ceilometer still needs to perform Nova API queries for some things, which scales badly with the number of running instances in a cloud and increases API load. What I'm proposing are additions to Nova's libvirt domain | |
| 16:27:40 | Callum027 | I'd appreciate feedback if anyone has any (sean-k-mooney has +1'd the spec and changes as an initial pass), and if everything looks good, approval to proceed with the patches created for this. | |
| 16:27:58 | gibi | btw this metadata in the libvirt xml helps with troubleshooting as it tells the details of the VM from the xml instead of looking it up form the logs of from a DB dump | |
| 16:28:22 | sean-k-mooney | yep | |
| 16:28:27 | gibi | so I'm supporting | |
| 16:28:29 | gibi | this | |
| 16:28:29 | sean-k-mooney | this is why i want to addm ore to it | |
| 16:28:44 | sean-k-mooney | i mean it help with billing and other ceilomenter usecases too | |
| 16:29:02 | sean-k-mooney | but if im being selfish having the info in the xml/logs means i do not have to ask supprot to ask a custoemr for it | |
| 16:29:17 | sean-k-mooney | so shortening that round trip time is a massive win IMO | |
| 16:29:26 | Callum027 | In our experience, having the flavour metadata was useful for helping determine how an instance ended up on a hypervisor | |
| 16:30:35 | Uggla | I understand we agree with this BP. Everybody ok with a specless one ? | |
| 16:31:10 | gibi | yeah I'm OK with it being a specless one | |
| 16:31:15 | sean-k-mooney | im supportive fo that and just proceedign witht he review and ensuring we have a good release note | |
| 16:32:19 | sean-k-mooney | there are some askpsec that woudl be nice to have beyond what Callum027 would liek to do. but i dont neesisarly want to expand the scope of there request to include them | |
| 16:32:37 | sean-k-mooney | so if we decied to work on those we can file a follow up bluepritn or revisit the discussion | |
| 16:33:00 | gibi | +1 on follow up and keep the scope small and land it quickly | |
| 16:33:37 | Callum027 | Sounds great, thanks guys, we've actually been using this in our production envs for a little while and it's been working great so I'm confident it's ready to go | |
| 16:33:59 | gibi | Callum027 thanks for working on it | |
| 16:34:05 | Uggla | Callum027, cool | |
| 16:34:38 | Callum027 | That's it from me Uggla, thanks | |
| 16:35:32 | Callum027 | Actually, do I need to add this to the Etherpad? | |
| 16:36:10 | Uggla | Callum027, it is ok, I have just updated it | |
| 16:36:24 | Callum027 | Awesome, thank you! | |
| 16:36:50 | Uggla | btw, thanks for joining this call. | |
| 16:37:21 | Uggla | I guess sean-k-mooney wanted to discuss this https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/NSW3OG5ME5RDPQYLHF4T4RCWPQYG57PK/ too | |
| 16:40:00 | gibi | it seems they have an RFE but they don't have a person volunteering to impelemnt | |
| 16:40:29 | gibi | I guess we can wait until we have somebody who at leat can propose a spec | |
| 16:40:33 | sean-k-mooney | /me clicks | |
| 16:40:47 | sean-k-mooney | oh that | |
| 16:40:47 | gibi | sean-k-mooney: this is the memballon RFE | |
| 16:41:07 | sean-k-mooney | ya i kind of felt like may i shoudl jsut spend an afternoon and write it | |
| 16:41:15 | sean-k-mooney | basicaly the short version is | |
| 16:41:33 | sean-k-mooney | nova orgianlly did not enabel the mem balloan at all unless you enabel memory stat reporting | |
| 16:41:45 | sean-k-mooney | at some point libvirt started adding it by default | |
| 16:41:59 | sean-k-mooney | but we have never actullly used it to release/reclaim unused memory form the guest | |
| 16:42:07 | sean-k-mooney | because that used to require a special agent on the host | |
| 16:42:17 | sean-k-mooney | proxmox and ovirt provided those | |
| 16:42:23 | sean-k-mooney | that now built into libvirt | |
| 16:42:36 | sean-k-mooney | so we coudl just hardcode 2 xml atributes | |
| 16:42:49 | sean-k-mooney | which woudl allwo memory to be release in 2 cases | |
| 16:43:14 | sean-k-mooney | oen when the OOM reaper is about to kill the vm if we have auto defalte on the vm gets a chane to free memory | |
| 16:43:24 | sean-k-mooney | the other one "freePageReporting" | |
| 16:43:40 | sean-k-mooney | allow the memory to be retruend to the host any time the guest free memory | |
| 16:43:52 | sean-k-mooney | i think it would nice ot supprot both in nova | |
| 16:44:08 | sean-k-mooney | but ya someone just needt to write it | |
| 16:44:32 | sean-k-mooney | i kind of wodnered how other felt | |
| 16:44:40 | gibi | if you have time to write it I'm not against it, but it is just a nice to have | |
| 16:45:09 | sean-k-mooney | track this as a wishlist RFE bug? | |
| 16:45:12 | sean-k-mooney | spec? | |
| 16:45:38 | sean-k-mooney | i feel like this is one of those things where is quicker to write then disucss :) | |
| 16:46:19 | Uggla | Yep that sounds quite strait forward so specless BP, I think. | |
| 16:46:23 | gibi | if this is hardcode as enalbed then specless | |
| 16:46:25 | sean-k-mooney | all of our qemu and linvert version miniums are above wehre this was added so there is no migration or upgrade aspect either | |
| 16:46:48 | gibi | does it effect realtime / nfv guest performance? | |
| 16:46:54 | sean-k-mooney | :) | |
| 16:47:13 | sean-k-mooney | well yes but they normlaly turn off the mem ballon entirly | |
| 16:47:22 | sean-k-mooney | because it addds overhead that they dont tolllerate | |
| 16:47:38 | sean-k-mooney | whicih is why we shoudl fix the bug that stops you form being able to do that | |
| 16:47:43 | gibi | ahh | |
| 16:47:50 | sean-k-mooney | https://bugs.launchpad.net/nova/+bug/2069192 | |
| 16:47:57 | gibi | so we should not make that situation worse :) Lets fix the bug first then | |
| 16:48:13 | sean-k-mooney | so this would be hard code on if you have the mem balloan enabled | |