Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2024-04-09
14:32:45 bauzas kashyap: you can look at https://ptg.opendev.org/ptg.html
14:33:29 kashyap Thanks!
14:43:31 bauzas fwiesel : we start discussing "nova on top of k8s"
14:44:15 sean-k-mooney ill joing the ptg soon fyi
14:44:33 sean-k-mooney i need to grab a drink before i do
15:02:08 bauzas melwitt: are you around ?
15:02:17 bauzas could you join us for unified limits ?
15:04:57 melwitt bauzas: yeah joining in a few
15:24:45 opendevreview Rafael Weingartner proposed openstack/nova master: Add logs for PCI passthrough device selection https://review.opendev.org/c/openstack/nova/+/915361
15:30:57 bauzas fwiesel: want to discuss "Compute node (instead host) for all scheduling operations and APIs" just after the unified limits discussion ?
15:35:16 bauzas nevermind, we'll discuss this tomorrow
15:42:59 dansmith bauzas: is that your keyboard being so loud?
15:43:10 bauzas not mine
15:43:17 dansmith okay
15:50:18 melwitt kashyap: thanks for taking notes on the etherpad about unified limits :)
15:51:27 kashyap melwitt: Happy to be a scribe :) Now I'm out of steam, so I stopped taking any notes on the current topics. (I've done one for an earlier, longer topic too)
16:02:57 bauzas haleyb: so, what about a nova-neutron session ? do you have specific bits in your agenda to share with us ?
16:40:17 haleyb bauzas: i think the only thing on my list was a continuation from last ptg as we never worked on the multiple port bindings items, that was all i had
16:41:18 bauzas haleyb: okay, do you think you need a nova audience for this then ?
16:44:43 haleyb bauzas: unclear, it's more of a reminder to pick up the work. it would be good to have a blueprint/rfe on what extensions need to be mandatory on the neutron side
16:45:11 bauzas haleyb: then, let's do a quick wrap on it on tomorrow if you want
16:48:08 haleyb bauzas: sure. i had created a time slot from 15:30-16:00 to talk about it if that works
16:48:21 haleyb or we can move things around a little
17:04:41 bauzas haleyb: we may have a conflicting session for discussing with the glance folks at the same time actually
17:04:58 bauzas haleyb: any possibility to move that 30-min chat ?
17:05:39 haleyb bauzas: can move to 15:00, does that work?
17:12:06 bauzas haleyb: yup, thanks !
17:12:15 bauzas I just added it to our etherpad
17:12:28 bauzas haleyb: we'll then go to your room
17:12:40 bauzas wfy ?
17:15:16 haleyb yes, works for me
17:15:18 haleyb thanks
17:16:51 bauzas haleyb: thanks
17:23:16 opendevreview ribaudr proposed openstack/nova master: Fix: migration configuration with cpu_shared_set (object part) https://review.opendev.org/c/openstack/nova/+/903706
17:23:16 opendevreview ribaudr proposed openstack/nova master: Fix: migration configuration with cpu_shared_set (libvirt part) https://review.opendev.org/c/openstack/nova/+/915139
17:23:17 opendevreview ribaudr proposed openstack/nova master: Test live migration between hosts with differnet cpu_shared_sets https://review.opendev.org/c/openstack/nova/+/913744
18:06:27 opendevreview Rafael Weingartner proposed openstack/nova master: Add logs for PCI passthrough device selection https://review.opendev.org/c/openstack/nova/+/915361
18:06:40 opendevreview Merged openstack/nova stable/2023.1: Power on cores for isolated emulator threads https://review.opendev.org/c/openstack/nova/+/913224
#openstack-nova - 2024-04-10
02:38:48 opendevreview Takashi Kajinami proposed openstack/nova master: libvirt: Use native DictOpt for disk_cachemode https://review.opendev.org/c/openstack/nova/+/915390
02:47:31 opendevreview Takashi Kajinami proposed openstack/nova master: libvirt: Validate valid cache mode at config input layer https://review.opendev.org/c/openstack/nova/+/915391
09:51:21 opendevreview Elod Illes proposed openstack/nova stable/2023.2: [ironic] Partition & use cache for list_instance* https://review.opendev.org/c/openstack/nova/+/906155
11:03:45 opendevreview Merged openstack/nova stable/2024.1: Fix nova-manage image_property show unexpected keyword https://review.opendev.org/c/openstack/nova/+/914671
12:38:12 opendevreview Merged openstack/nova stable/zed: Remove outdated comment about allocation ratios https://review.opendev.org/c/openstack/nova/+/908692
12:52:46 bauzas fwiesel: tkajinam: hey, which one of you both would want to start to discuss about your topics ?
12:53:03 bauzas Extending memory encryption support or Nova Metadata Optimization ?
12:57:01 fwiesel bauzas: No strong preference. It would just be good to be finished with the metadata optimization before the neutron cross project call.
12:57:37 tkajinam the other 3 topis are mine it seems so I'm fine with metadata discussion going first
12:58:00 bauzas fwiesel: tkajinam: cool, we'll start with the metadata, thanks
13:50:54 opendevreview Merged openstack/nova stable/2023.1: pwr mgmt: make API into a per-driver object https://review.opendev.org/c/openstack/nova/+/913225
14:11:02 opendevreview Merged openstack/nova stable/2023.2: Fix nova-manage image_property show unexpected keyword https://review.opendev.org/c/openstack/nova/+/914765
14:33:12 zigo I still have this bug open, unaddress since 2021: https://bugs.debian.org/982241
14:33:12 zigo Can nova use something else than genisoimage? If not, it'd be a good idea to make it support xorriso ...
14:34:29 tkajinam zigo, ROD switched to xorriso. probably you can follow the same patch. There is a patch to update the default but has been stall. if other distros follow that switch then we can move the defualt switch forward
14:34:58 zigo tkajinam: Just switching the config option is enough?
14:36:48 clarkb zigo: if that is for config drive building then I think nova can also make a fat32 instead of an iso9660 image
14:53:47 zigo clarkb: Well, grep -r genisoimage points to config drive building indeed.
14:54:15 zigo I'd prefer if I could just switch to xorriso easily... :/
14:54:21 zigo tkajinam: Do you have the patch handy?
14:54:59 tkajinam zigo, I'm in ptg sessions so will update you sometime later
14:55:08 zigo Thanks.
15:02:08 tkajinam bauzas, I'll take some break during cross project discussion with neutron so please ping me when we resume nova discussions
15:02:12 bauzas ++
15:02:52 tkajinam I'll try to summarize the discussion during that time, too. sorry I was mostly listening but there were some good points raised during the time
15:03:13 opendevreview Merged openstack/nova stable/2023.1: Reproducer test for live migration with power management https://review.opendev.org/c/openstack/nova/+/913226
15:14:17 kashyap tkajinam: Hi, a note on that AMD SEV-ES thing: when you get time, see my comments on the spec - https://review.opendev.org/c/openstack/nova-specs/+/907702
15:15:34 kashyap tkajinam: The main question to think of is: SEV-ES processors are vulnerable to attestation attacks (see the links I provided). SEV-SNP fixes those problems.
15:16:12 kashyap tkajinam: So we should be careful in not investing too much effort on something that will soon be "replaced" / taken over by its next-gen tech (SEV-SNP)
15:16:28 kashyap You can write your thoughts on the spec. I mentioned my concerns there too.
15:17:07 tkajinam kashyap, thanks !
15:17:13 kashyap It looks like, we won't get to that topic today. So let's keep the discussion on the Etherpad / spec :-)
15:17:51 kashyap tkajinam: A year ago or so, I've spent some time testing SEV-SNP. I need to refresh on it, though. I'll do some more analysis on where are various low-level projects on it, and get back
15:18:18 tkajinam (I'll post the same comments in etherpad and spec but) I agree that we should be careful about the investment. tbvh this work to support SEV-ES is more like a practice of extending the current implementation so that we can quickly work on SEV-SNP
15:19:26 tkajinam once the whole implementations are merged in upstream
15:22:25 kashyap Yeah, I see your point, but we shouldn't go deep into ES-specific impl details in Nova.
15:25:19 tkajinam We have already built PoC with patched kernel/qemu/libvirt/openstack to test SEV-SNP and the proposal is based on the learning in that work. the items specific to SEV-ES is the detection of ES capability and additional policy flag bit in libvirt and the other parts will be reused by SEV-SNP
15:28:36 bauzas tkajinam: Extending memory encryption support is planned at 1545UTC
15:28:54 bauzas now this is break time
15:29:00 tkajinam bauzas, ack. thanks
15:30:24 dansmith melwitt: the glance encryption thing will be in the cinder room, fyi
15:30:42 melwitt dansmith: ah ok, thanks
15:31:12 dansmith melwitt: nowish
15:31:19 melwitt oh, k
15:31:24 dansmith if you can
17:15:06 bauzas tobias-urdin: oh shit, just saw you weren't available neither today or tomorrow :(
17:15:26 bauzas any possibility tho to join us for only one hour ?
17:15:41 bauzas I can arrange ourselves on a specific time for you
17:17:14 bauzas stephenfin: are you okay discussing your topic tomorrow ?
17:18:55 kashyap bauzas: I missed the 17:45 slot :( But I added my thoughts in the Etherpad and the spec
17:19:04 bauzas np
17:21:14 kashyap tkajinam: Okay, we can talk more tomm. So you've also been testing SNP based on upstream on-list patches? I'm not sure who you mean by "we" :)
17:22:06 tkajinam kashyap, sure
17:24:11 tkajinam kashyap, I'm now part of a small team here in NTT DATA(my current employer), we have been using kernel/qemu/ovmf maintained in https://github.com/AMDESE (I think these contain patches proposed in lists) with libvirt and OpenStack additionally patched.
17:26:17 kashyap tkajinam: Ah, I see. Nice. I work w/ some of the confidential computing folks at RHT. Although, I'm not up2date on this area now, I poked some the SEV-SNP stuff w/ `sevtool`, etc back on Oct 2022.
17:27:14 tkajinam We've built a small PoC system which provides VM with its memory and disk encrypted and protected from hosts. Because we wanted some mechanism to detect any tampered bootchain elements(like kernel with any backdoor installed) we decided to use SEV-SNP which was most heading last year. I saw some works have done recently by Intel and am planning to try Intel TDX this year as well.
17:27:15 kashyap s/back on/back in/
17:28:22 kashyap tkajinam: I see, nice. Do you also care about the whole attestation / measured boot thing? (I'm guessing you do)
17:28:34 tkajinam kashyap, yeah, I read their articles actually during my on-boarding process.
17:29:11 kashyap tkajinam: Nice. Shameless plug, I once wrote this too, but I'm a bit out-of-date now :D - https://lwn.net/Articles/838488/
17:29:56 kashyap Some of the tools mentioned at the end got deprecated, or new tools came in. And the "remote attestation" problem noted there is still a bit of a "beast" upstream, w/ various vendors coming up with their schemes.
17:30:15 kashyap tkajinam: Consolidating on one approach to remote attestation seems to be a multi-year effort.

Earlier   Later