| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2025-09-30 | |||
| 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 | gibi | sounds like a plan | |
| 16:49:52 | r-taketn | That's all from me today. thanks all. | |
| 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 | opendevmeet | Log: https://meetings.opendev.org/meetings/nova/2025/nova.2025-09-30-16.01.log.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 | Minutes: https://meetings.opendev.org/meetings/nova/2025/nova.2025-09-30-16.01.html | |
| 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 | Uggla | #endmeeting | |
| 16:57:20 | r-taketn | Thank you | |
| 16:57:28 | elodilles | thanks o/ | |
| 16:58:10 | gibi | o/ | |
| 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:58:42 | sean-k-mooney | Uggla: im triaging https://bugs.launchpad.net/nova/+bug/2125738 as low but its valid just an fyi | |
| 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 | |
| 17:21:30 | lajoskatona | SDK has general httpException, that can be used for such | |
| 17:22:35 | opendevreview | Takashi Kajinami proposed openstack/nova master: AMD SEV: omit iommu='on' for virtio devices https://review.opendev.org/c/openstack/nova/+/909635 | |
| 17:22:38 | sean-k-mooney | so neutron_client_exc.OverQuotaClient apars ot be the oen that is missing | |
| 17:22:55 | sean-k-mooney | right we are nologner rasign FloatingIpLimitExceeded | |
| 17:23:35 | sean-k-mooney | so for partity we would need to disambiuage the sdk_exc.ConflictException | |
| 17:23:57 | sean-k-mooney | and look at the message to know if its a quota issue or if we are out of ips | |
| 17:25:26 | sean-k-mooney | i think in both case we would expect the allocation to fail and we would want to return a 409 | |
| 17:25:47 | sean-k-mooney | so merging those together while it makes debuging hard does not seam to alter the api behavior | |
| 17:26:48 | sean-k-mooney | lajoskatona: are you wonderign if nova shoudl do that disambiguation ro if it shoudl be in the sdk | |
| 17:27:08 | sean-k-mooney | or are you wonderign if its required to treat them differently vs merging them into a singel expction | |
| 17:27:14 | lajoskatona | sean-k-mooney: +1, I check it tomorrow to look inside the message | |
| 17:27:57 | lajoskatona | sean-k-mooney: My first idea was to merge them | |
| 17:28:19 | sean-k-mooney | i think as long as the end result at the api/externally does nto change i.e. 409 | |
| 17:28:28 | sean-k-mooney | adn we have somethign reasonable in the debug logs | |
| 17:28:36 | lajoskatona | sean-k-mooney: for tomorrow I will have more test results from zuul, so I will see if this aproach can work :-) | |
| 17:28:37 | sean-k-mooney | so we can tell which it actully was its proably oke to merge them | |
| 17:28:46 | sean-k-mooney | ack | |