| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2025-09-30 | |||
| 16:31:14 | Uggla | for the upstream meetings. | |
| 16:32:16 | Uggla | Last week I managed to collect some trends, so I can narrow a bit the choices. | |
| 16:33:06 | Uggla | That's all 4 me. | |
| 16:33:42 | Uggla | Does anyone whant to discuss about something ? | |
| 16:33:46 | r-taketn | Uggla: I've just added one more topic to the agenda right before the meeting. Can I share it now? | |
| 16:34:23 | Uggla | Sure, sorry I missed it because my mage was not refreshed. | |
| 16:34:31 | Uggla | please go ahead r-taketn | |
| 16:34:33 | r-taketn | Thank you | |
| 16:34:41 | r-taketn | #link https://review.opendev.org/c/openstack/nova-specs/+/962578 | |
| 16:34:51 | r-taketn | We proposed to adjust the existing SEV/SEV-ES code. | |
| 16:35:03 | r-taketn | We think there is the need to generalize the existing SEV/SEV-ES code a bit to support other confidential computing features (e.g. Intel TDX, Arm CCA). | |
| 16:35:29 | r-taketn | We would like to discuss the timing of this introduction. Specifically, we propose this as a standalone enhancement in advance to accept other features. Could we consider this approach? | |
| 16:36:41 | gibi | I feel like this needs a spec and a PTG discussion and we need tkajinam present :) | |
| 16:37:11 | sean-k-mooney | +1 to ^ | |
| 16:37:22 | Uggla | gibi spec link above, but I agree to with ^ | |
| 16:37:34 | tkajinam | :-) | |
| 16:37:37 | sean-k-mooney | but the overall intent is to generalise teh code now so that it can be extended in teh future correct for more usecase and or vendors/plathforms | |
| 16:37:56 | tkajinam | yeah like CCA and even TDX | |
| 16:38:06 | r-taketn | sean-k-mooney: yes | |
| 16:38:16 | sean-k-mooney | we have talked about TDX in the past as soemting that shoule eventually be supproted | |
| 16:38:31 | Uggla | that sounds a reasonable "refactoring" | |
| 16:38:45 | tkajinam | I'll check the spec and try to leave some feedback there for the discussion | |
| 16:38:56 | gibi | Uggla: I blame the clock for not noticing the spec link :) | |
| 16:39:08 | r-taketn | tkajinami: Thank you. | |
| 16:39:44 | tkajinam | my quick suggestion at my first glance is that if you can put more focus on describing the expected problems of the current code, rather than how you update codes in details, that would help us understand the direction. | |
| 16:40:07 | Uggla | I can say that my employer is interested in TDX and CCA support at some point. | |
| 16:40:50 | Uggla | tkajinam +1 | |
| 16:41:21 | sean-k-mooney | on thing i will say just glancing at it | |
| 16:41:23 | sean-k-mooney | MemEncryptionConfig | |
| 16:41:25 | r-taketn | tkajinami: Thank you for your feedbacks. I will clarify the purpose and merit to merge this refactoring in advance more. | |
| 16:41:37 | sean-k-mooney | is currently a named touple or inhertied form it | |
| 16:41:55 | sean-k-mooney | we may actully want to formmalise that inot a real class if we intend to build out more functionality with it | |
| 16:42:04 | sean-k-mooney | i.e. have properties/functions assocated with it | |
| 16:42:33 | sean-k-mooney | espcially if this woudl ever be inlcuded in any rpc object | |
| 16:42:47 | sean-k-mooney | but we can reviw that as part of the spec | |
| 16:43:23 | tkajinam | yeah | |
| 16:43:39 | Uggla | sean-k-mooney +1, tuple is evil. :) | |
| 16:43:54 | tkajinam | I'm guessing we may need to convert it to a class and create sub class per mechanisms. | |
| 16:44:02 | sean-k-mooney | named tupples are less so but if we ever thing that class will be part fo an rpc call | |
| 16:44:07 | sean-k-mooney | then it need to be an ovo | |
| 16:44:29 | sean-k-mooney | ffor now its not so its fine so again lets look at that when we think about the generalisation | |
| 16:44:39 | tkajinam | yeah | |
| 16:44:59 | sean-k-mooney | it may not be relevent but nova.virt.hardware is used in the schdler and the computes already and maybe the conductor | |
| 16:45:21 | sean-k-mooney | anyway i dont really ahve anythign else on that | |
| 16:47:42 | r-taketn | Thank you for some feedbacks. My intent is the same to the above discussion(Specifically, MemEncryptionConfig) | |
| 16:48:32 | r-taketn | Anyway, I need to write the spec in detail more. | |
| 16:49:33 | r-taketn | I will improve the spec constantly. It would be helpful if we could discuss this at PTG or on Gerrit. | |
| 16:49:52 | r-taketn | That's all from me today. thanks all. | |
| 16:49:52 | gibi | sounds like a plan | |
| 16:50:12 | Uggla | r-taketn 👍 | |
| 16:50:30 | Uggla | Anything else to discuss. | |
| 16:50:37 | gibi | - | |
| 16:50:49 | tkajinam | nothing from me | |
| 16:52:07 | bauzas | - | |
| 16:52:48 | Uggla | #topic Bug scrubbing | |
| 16:52:56 | Uggla | #info up to 186 (+9 from previous week :( ) | |
| 16:53:23 | Uggla | ^ just providing the info that it increases a lot compare to last week. | |
| 16:53:50 | Uggla | I know gibi is contributing to it. ;) | |
| 16:54:33 | Uggla | I will try to look at them tomorrow, if I can answer/close some of them. | |
| 16:54:49 | Uggla | Anyway I think that's all for today. | |
| 16:55:38 | gibi | hey, I saw bugs, I open trackers :) | |
| 16:56:55 | Uggla | Thank you for participating in this meeting. I’ll keep you posted if the next meeting is rescheduled. | |
| 16:57:12 | Uggla | #endmeeting | |
| 16:57:12 | opendevmeet | Meeting ended Tue Sep 30 16:57:12 2025 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | |
| 16:57:12 | opendevmeet | Minutes: https://meetings.opendev.org/meetings/nova/2025/nova.2025-09-30-16.01.html | |
| 16:57:12 | opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/nova/2025/nova.2025-09-30-16.01.txt | |
| 16:57:12 | opendevmeet | Log: https://meetings.opendev.org/meetings/nova/2025/nova.2025-09-30-16.01.log.html | |
| 16:57:20 | r-taketn | Thank you | |
| 16:57:28 | elodilles | thanks o/ | |
| 16:58:10 | gibi | o/ | |
| 16:58:42 | sean-k-mooney | Uggla: im triaging https://bugs.launchpad.net/nova/+bug/2125738 as low but its valid just an fyi | |
| 16:58:42 | elodilles | Uggla: fyi, the nova ptg etherpad link is not updated on the ptg page: https://ptg.opendev.org/etherpads.html | |
| 16:59:05 | opendevreview | Lajos Katona proposed openstack/nova master: Use SDK for Neutron floating IPs https://review.opendev.org/c/openstack/nova/+/962604 | |
| 16:59:17 | elodilles | Uggla: i think it can be updated via the openinfraptg bot in #openinfra-events channel | |
| 16:59:41 | sean-k-mooney | its a fairly simpel fix in out bindep.txt to account for the package change | |
| 17:00:45 | lajoskatona | Uggla: Hi, just a quick note that I slowly progress with the migration to SDK from neutronclient hell: https://review.opendev.org/q/topic:%22sdk_for_neutron%22 , after we are over the release week we can discuss how should it be consumed the easiest way :-) | |
| 17:00:58 | sean-k-mooney | its not actully a bug requriing nova code change really beyond bindeps.txt to just document the relevent dep | |
| 17:01:45 | sean-k-mooney | lajoskatona: ya you have broken it up that helps | |
| 17:02:18 | sean-k-mooney | i likmed the orginal patch and saw you were updating it but i have not looked at it in any detial | |
| 17:02:34 | sean-k-mooney | s/likmed/skimed/ | |
| 17:04:43 | sean-k-mooney | lajoskatona: we have a related topic for the wtacher ptg about how/wen to start the convertion tothe sdk there. there is a depency on the neutron client in watcher too https://github.com/openstack/watcher/blob/master/requirements.txt#L38 | |
| 17:05:28 | sean-k-mooney | but really not much of one today so i was sugesting we start with movaing the novaclinet and perhaps other over to the sdk next cycle | |
| 17:06:09 | Uggla | sean-k-mooney, elodilles I will look at above later. | |
| 17:09:11 | lajoskatona | sean-k-mooney: The thing that I run into and have to think about is that in n-client there are plenty of exotic exceptions like overquota and similar, but SDK has only basic exceptions like conflict | |
| 17:10:09 | lajoskatona | at the moment I am not sure if using the simple conflict, notfound etc is enough or there is a need for cover the neutronclient exotic exceptions in SDK for example | |
| 17:11:57 | sean-k-mooney | lajoskatona: ah so we may need to add some more detailed excption n nova for those diffent usecases to make the rest of the logic continue to work the same | |
| 17:12:31 | sean-k-mooney | and your tryign to understand if that is the correct approch or if the nova code should be adapted to the geneirc expctions? | |
| 17:12:46 | sean-k-mooney | it that the crux of the disucssion you want to have | |
| 17:13:24 | sean-k-mooney | i.e. adtapt the generic excption to specific ones locally at the callsite or not? | |
| 17:16:20 | sean-k-mooney | lajoskatona: for the most part as you have seen here https://review.opendev.org/c/openstack/nova/+/928022/12/nova/network/neutron.py#2933 we have tired to convert the neutron client excption into nova specific ones rather then propagate them outside ot the nova.network.neutron module | |
| 17:16:56 | sean-k-mooney | so ideally code outside of nova/network/neutron.py shoudl not need to deal with sdk or neutron client excptions | |
| 17:17:08 | sean-k-mooney | lajoskatona: alhtough i dont know if that is actully what you are asking | |
| 17:19:11 | lajoskatona | sean-k-mooney: yes that is my problem now, I think the fresh patch for FIPs has some of these cases | |
| 17:19:14 | sean-k-mooney | https://review.opendev.org/c/openstack/nova/+/962604/1/nova/network/neutron.py#b2949 | |
| 17:19:20 | sean-k-mooney | this is perhaps a good example | |
| 17:19:56 | sean-k-mooney | before if it was not a client excption we loged the ecetpion and reaised | |
| 17:20:37 | lajoskatona | or some real exotic ones: https://review.opendev.org/c/openstack/nova/+/962604/1/nova/network/neutron.py#3100 :-) | |
| 17:20:42 | sean-k-mooney | we still proably shoudl actch other clent excptions and log them and then raise them again | |
| 17:21:06 | sean-k-mooney | ah | |
| 17:21:17 | sean-k-mooney | except (neutron_client_exc.IpAddressGenerationFailureClient, neutron_client_exc.ExternalIpAddressExhaustedClient | |