| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2025-09-30 | |||
| 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 | |
| 17:29:22 | sean-k-mooney | so for th ecase like this you could consider doing the merge in a seperate refactor first | |
| 17:29:54 | sean-k-mooney | then the adopt sdk patch is just doing that | |
| 17:30:17 | sean-k-mooney | i have not reviewd this in detail but in most cases i tlooks like you have found 1:1 mappings | |
| 17:30:37 | sean-k-mooney | but sure let me know what you find after zuul reports | |
| 17:31:17 | sean-k-mooney | lajoskatona: as an aside i think https://github.com/openstack/watcher/blob/master/watcher/common/nova_helper.py#L729-L744 is the only useage of neutronclient in watcher | |
| 17:31:38 | sean-k-mooney | and i dont think we actully need that info really any more | |
| 17:31:47 | sean-k-mooney | its part of the create_instance helper https://github.com/openstack/watcher/blob/master/watcher/common/nova_helper.py#L641 | |
| 17:31:56 | sean-k-mooney | and that on my todolist to see fi we can entrily delete | |