Thanks for the great summary, Sylvain ! Let me leave a few comments inline for some topics. On 4/23/24 02:43, Sylvain Bauza wrote: <snip>
### Unified limits default behaviour with no registered limits ###
We discussed some specific case you have today with unified limits : you need to register all the limits for all the resource classes you use for flavors, because if not, you wouldn't have quotas for them. We then agreed on the fact that all the 'core' resource classes (meaning the non-custom ones) should be registered. melwitt will provide a document for explaining it. For custom resource classes, we agreed on providing a relax mode (in the nova configuration) for accepting unregistered limits only for custom resource classes. That option would also have a strict mode for asking to register even the custom RCs.
Unfortunately I could not join the discussion because of conflicting schedules but I'm curious to know if any change is needed in oslo.limits side to support this use case (because of my oslo-core hat). I'm aware that there are a few patches already proposed but please feel free to pull me to oslo.limits patch reviews once these are updated (if needed) according to the agreement in PTG. # I'll go through the discussion log later this week.
### Extending memory encryption support ###
For the moment, Nova only supports AMD-SEV for encrypting the instance memory. We discussed about two other hardware supports : AMD-SEV-ES and SGX. For AMD SEV-ES (new AMD SEV generation), we agreed on documenting some not configuration support by BIOS, modifying the inventories by using nested resource providers with the same resource class and maybe needing some reshape. Takashi will work on it for this cycle (live-migration wouldn't be done by this cycle) For SGX, we said we need a new blueprint and a spec. We are OK to create a new nested resource provider for the resource class, but we would like to know the current move operation limitations.
I've updated the spec[1] based on the discussion but please let me know if I didn't capture our agreements well. For example I'm not sure if we want to document the reshape logic in detail (and the current version does not contain the details) would appreciate any feedback. [1] https://review.opendev.org/c/openstack/nova-specs/+/907702
### Stateless firmware support ###
Even if the libvirt driver recreates a new firmware when we're moving/resizing an instance, we discussed whether we should support a specific stateless firmware. We agreed on accepting it, so takashi will work on it, but will also fix the related bug reports [3].
To be very honest, fixing the issue with current "statefull" firmware is out of my current scope. I may be able to look into these when I get time but I can't commit on it now because of my own capacity, and I believe the fixing statefull firmware is independent from the stateless firmware support work.
### Automatically detecting vTPM support ###
Long story short, we accepted [4] as a specless blueprint. takashi will work on the implementation this cycle.
<snip>
### EOF ###
That's a wrap now, my fingers are now quite bloody (they're not used to write that much). Sorry for the long summary, I just hope your coffee (or tea) was good.
Again, thanks for your nice summary and also good moderation during the vPTG !
-Sylvain (who could have written his last PTG summary email if planets align)
[1] https://etherpad.opendev.org/p/nova-dalmatian-pt <https://etherpad.opendev.org/p/nova-dalmatian-pt> g (please remove the empty char between 'pt' and 'g') [2] https://bugs.launchpad.net/nova/+bug/2058928 <https://bugs.launchpad.net/nova/+bug/2058928> [3] https://bugs.launchpad.net/nova/+bug/1785123 <https://bugs.launchpad.net/nova/+bug/1785123>and https://bugs.launchpad.net/nova/+bug/1633447 <https://bugs.launchpad.net/nova/+bug/1633447> [4] https://blueprints.launchpad.net/nova/+spec/libvirt-detect-vtpm-support <https://blueprints.launchpad.net/nova/+spec/libvirt-detect-vtpm-support> [5] https://review.opendev.org/c/openstack/nova-specs/+/863884 <https://review.opendev.org/c/openstack/nova-specs/+/863884> [6] https://review.opendev.org/c/openstack/nova-specs/+/909448 <https://review.opendev.org/c/openstack/nova-specs/+/909448> [7] https://review.opendev.org/c/openstack/nova-specs/+/915190 <https://review.opendev.org/c/openstack/nova-specs/+/915190>