| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2025-05-27 | |||
| 16:10:11 | dansmith | merged may 20 | |
| 16:10:44 | gibi | I last checked on the 19th | |
| 16:10:50 | gibi | I can check for hits since then... | |
| 16:10:59 | dansmith | tl;dr the new glance location API is fundamentally broken for ceph and cinder backends, we reverted nova's use of it while working on a solution for those backends in glance | |
| 16:12:19 | Uggla | thx for the info dan | |
| 16:12:23 | gibi | I see two hits after 20th | |
| 16:12:24 | gibi | | 455491157c0f44cebf2cfcfe9f1c7b5c | 2025-05-22T07:20:41 | check | https://review.opendev.org/950623 | master | | |
| 16:12:27 | gibi | | f61be3ef2b9a442d8843f65152343018 | 2025-05-20T12:55:29 | check | https://review.opendev.org/948450 | master | | |
| 16:12:48 | dansmith | one is the revert of revert, so expected | |
| 16:13:01 | dansmith | the other is too close to merge, probably used old code | |
| 16:13:09 | gibi | OK then maybe we are moving to the good direction | |
| 16:13:14 | gibi | dansmith: thanks for the info | |
| 16:13:17 | dansmith | np | |
| 16:13:36 | Uggla | ok mobing on | |
| 16:13:37 | Uggla | #topic tempest-with-latest-microversion job status | |
| 16:13:47 | Uggla | #link https://zuul.opendev.org/t/openstack/builds?job_name=tempest-with-latest-microversion&skip=0 | |
| 16:13:59 | gmaan | no new update this week | |
| 16:14:11 | Uggla | ok so let's continue | |
| 16:14:27 | Uggla | #topic Release Planning | |
| 16:14:34 | Uggla | #link https://releases.openstack.org/flamingo/schedule.html | |
| 16:14:44 | Uggla | #info Nova deadlines are set in the above schedule | |
| 16:15:01 | Uggla | #info Only 1 weeks before Nova Spec Soft Freeze, do not forget to submit your specs. | |
| 16:15:35 | Uggla | #topic Review priorities | |
| 16:15:45 | Uggla | #link https://etherpad.opendev.org/p/nova-2025.2-status | |
| 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 | |