| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2026-07-27 | |||
| 16:05:19 | elodilles | just discovered this today ^^^ | |
| 16:05:36 | elodilles | #info other stable gates should be OK | |
| 16:05:42 | elodilles | #info stable branch status / gate failures tracking etherpad: https://etherpad.opendev.org/p/nova-stable-branch-ci | |
| 16:05:52 | elodilles | some details about the failure here as well ^^^ | |
| 16:06:17 | elodilles | and that's all from me. any review on the above trivial gate fix is welcome o:) | |
| 16:06:30 | elodilles | i'll backport it if the master version merges | |
| 16:06:41 | elodilles | bauzas: back to you | |
| 16:07:04 | bauzas | cool thanks | |
| 16:07:11 | bauzas | #topic vmwareapi 3rd-party CI efforts Highlights | |
| 16:07:17 | bauzas | fwiesel: hello :) | |
| 16:07:20 | fwiesel | Hi, no updates from my side. | |
| 16:07:25 | bauzas | cool thanks | |
| 16:07:30 | bauzas | #topic Kamil's news about eventlet removal | |
| 16:07:48 | bauzas | sambork: hello :) | |
| 16:08:04 | sambork | o/ | |
| 16:08:25 | sambork | Since last Monday, one patch has merged: 998136 (startup config dump), along with a follow-up from gmaan in Oslo. Additionally, two patches from gibi have landed in review (998001 and 997719), both focused on test stabilization—plus a bunch of additional patches proposed right before the meeting | |
| 16:09:44 | sean-k-mooney | sambork: are we going to reviert that when its fixed in oslo | |
| 16:09:57 | sambork | yes | |
| 16:10:16 | sambork | we also discussed potential issues found during performance testing (mostly memory consumption), but we haven't had time to investigate further yet. Anything to add, gibi? | |
| 16:10:25 | sean-k-mooney | ack if you havnt created it it woudl be good to create teh revert with the depen on again oslo but no rush really | |
| 16:10:38 | sambork | ack, will do thanks! | |
| 16:11:08 | opendevreview | Takashi Kajinami proposed openstack/osc-placement master: tox: Fix outdated functional test environments https://review.opendev.org/c/openstack/osc-placement/+/998825 | |
| 16:11:32 | sambork | if not then back to you bauzas | |
| 16:11:40 | bauzas | moving on ? | |
| 16:11:46 | bauzas | cool thbanks | |
| 16:11:53 | bauzas | #topic Nova using openstack sdk for neutron | |
| 16:11:58 | bauzas | -ETOOMANYTOPICS | |
| 16:12:07 | bauzas | lajoskatona: hello :) | |
| 16:12:08 | lajoskatona | Hi | |
| 16:12:30 | lajoskatona | One news (actually not fresh, just before my PTO) : https://review.opendev.org/c/openstack/openstacksdk/+/995724 | |
| 16:13:06 | lajoskatona | in SDK we can use similar filtering for fields what we have with neutronclient if we merge and release this | |
| 16:14:07 | lajoskatona | actually that's it, if it is merged + released I can make it used by the already reviewd patches | |
| 16:14:56 | sean-k-mooney | cool | |
| 16:15:17 | sean-k-mooney | correct me if im mistaken but when we pass the feils we care about | |
| 16:15:20 | bauzas | moving on ? | |
| 16:15:26 | sean-k-mooney | neutonc can actully do less work right | |
| 16:15:30 | sean-k-mooney | in somecase at least | |
| 16:15:33 | lajoskatona | yes | |
| 16:15:36 | sean-k-mooney | its not just reducing the payload | |
| 16:15:42 | lajoskatona | and Neutron APi itself | |
| 16:15:55 | sean-k-mooney | ya so its good to keep that optimisation | |
| 16:16:06 | sean-k-mooney | i have no other questions so we can move on | |
| 16:16:23 | bauzas | cool | |
| 16:16:30 | bauzas | #topic Ironic review priorities | |
| 16:16:33 | bauzas | who to ping ? | |
| 16:16:41 | lajoskatona | strange is that it is not used in SDK currently, the kind of engine is there, but not used by resources, so good goal for all SDK resources | |
| 16:17:07 | bauzas | I guess we can move on | |
| 16:17:13 | bauzas | #topic Confidential computing, status of SNP and TDX features | |
| 16:17:21 | bauzas | tkajinam: or gibi: maybe ? | |
| 16:17:33 | bauzas | -ETOOMANYTOPICS again sorry | |
| 16:18:04 | tkajinam | the current focus is TDX support because the changes for SNP have been merged. | |
| 16:18:09 | bauzas | right | |
| 16:18:19 | bauzas | I just copied from the agenda :) | |
| 16:18:32 | antia | TDX is coming along. Made good progress last week and currently working on the actual vm creation | |
| 16:18:35 | tkajinam | gibi and I reviewed the patches proposed by antia and I think all these are settled but we are still waiting for the remaining changes for completing the feature | |
| 16:18:43 | bauzas | ++ | |
| 16:18:43 | tkajinam | yeah | |
| 16:18:45 | gibi | yepp | |
| 16:18:48 | gibi | nothing to add | |
| 16:18:53 | gibi | I will continue reviewing | |
| 16:19:00 | antia | Thanks for the reviews btw | |
| 16:19:01 | bauzas | cool, I guess we can move on | |
| 16:19:07 | tkajinam | ++ | |
| 16:19:11 | bauzas | #topic Bug scrubbing | |
| 16:19:19 | bauzas | #link https://etherpad.opendev.org/p/nova-bug-triage-roster | |
| 16:19:25 | bauzas | #link https://truc.uggla.fr/ to follow the trend. | |
| 16:19:35 | bauzas | I won't run bug triage meeting this week | |
| 16:20:09 | bauzas | then, someone added "Support for Hostname-based Ceph Mon References " | |
| 16:20:19 | bauzas | but let's do this in the open discussion | |
| 16:20:25 | bauzas | #topic Open discussion | |
| 16:20:34 | bauzas | #item Support for Hostname-based Ceph Mon References | |
| 16:20:38 | bauzas | who wrote this ? | |
| 16:20:44 | Leo[m] | Hello, that was me | |
| 16:20:53 | Leo[m] | open to the idea of having a configuration that allows users to choose to use hostnames instead of IP addresses? Or, is there any other way that you would prefer to solve this problem? Could the mon addresses be read from nova.conf or ceph.conf instead? Thank you for your time! Leo | |
| 16:20:53 | Leo[m] | Hello, I hope everyone is doing well. My name is Leo Jenkins and I’m an engineer from Bloomberg. At the moment, ceph mon dump is used to get the IP addresses of the cloud’s Ceph mons. This makes it difficult to change the hardware or upgrade to IPv6. We have a loose commitment from the upstream Ceph community to add a —hostname flag to ceph mon dump to have it return the Ceph mon hostnames. If Ceph does this, would Nova be | |
| 16:21:36 | bauzas | Leo[m]: I don't think this should be a nova.conf option | |
| 16:22:36 | Leo[m] | Ok, sounds good. What do you recommend instead? | |
| 16:22:38 | sean-k-mooney | Leo[m]: so today there are 2 ways we interact with ceph | |
| 16:22:47 | sean-k-mooney | either vai the cidner connection details | |
| 16:22:52 | sean-k-mooney | or directly | |
| 16:22:58 | bauzas | that being said, we have a few ceph options https://docs.openstack.org/nova/latest/configuration/config.html#libvirt.ceph_mount_point_base | |
| 16:23:01 | sean-k-mooney | and when we conenct directly we depend on the ceph.conf | |
| 16:23:10 | sean-k-mooney | ususlly under /etc/ceph | |
| 16:23:29 | sean-k-mooney | so if this was all handeeld internally via ceph.conf and the relevent cli/python bindings | |
| 16:23:42 | Leo[m] | https://github.com/openstack/nova/blob/9e1434d255f59f10c0fdf75c3fe6bebfa315df10/nova/storage/rbd_utils.py#L191 | |
| 16:23:42 | Leo[m] | This is the specific code in question by the way in case that is not clear | |
| 16:24:14 | sean-k-mooney | it woudl be transparent to nova when using image_type=rbd | |
| 16:24:42 | sean-k-mooney | so that the codepath that still uses the clint | |
| 16:25:26 | sean-k-mooney | but i beivle its finding the mons via the ceph.conf | |
| 16:25:42 | sean-k-mooney | i guess waht you really want is for us to have an option to use the mon fqdn | |
| 16:25:46 | sean-k-mooney | in teh rbd url | |
| 16:25:57 | sean-k-mooney | if that was supproted in qemu ectra | |
| 16:27:26 | sean-k-mooney | Leo[m]: i think this woudl likely need a spec or a specless blueprint | |
| 16:27:58 | sean-k-mooney | Leo[m]: but i dont think the ide of decopleing form the ip and allowing a hostnaem or fqdn woudl be problematic | |
| 16:28:21 | sean-k-mooney | we woudl just need to ensure we properly supprot that across the stack (libvirt,qemu,ceph client, nova) | |
| 16:28:41 | Leo[m] | Ok, good to know. I can create a blueprint and follow up in a future meeting | |
| 16:28:46 | tkajinam | I'm wondering if that option needs to be backend specific ? or can be common for all ceph clusters | |
| 16:29:27 | tkajinam | and probably we should also decide whether we should take care of migration between two nodes with old ceph / new ceph | |
| 16:29:32 | bauzas | let's discuss this once we have the blueprint but sure :) | |
| 16:29:35 | tkajinam | but that could be discussed further in spec/bp | |