Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2025-09-30
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
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

Earlier   Later