| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2025-01-28 | |||
| 16:34:14 | sean-k-mooney | but it can be proposed for next cycle if the hardware is aviable | |
| 16:34:47 | sean-k-mooney | we only merge hardware enabling code after the hardware is generally aviabel in teh market not before | |
| 16:34:51 | bauzas | yes indeed, there are a few limitations that you should be aware | |
| 16:35:17 | r-taketn | To our knowledge, no products currently support Arm CCA. FUJITSU-MONAKA [1], scheduled for release by Fujitsu in 2027, may be the first such product. | |
| 16:35:20 | bauzas | usually, we would want to make sure that our upstream CI can test specific hardware | |
| 16:35:46 | bauzas | if specific hardware can't be tested on upstream CI, then there are two possibilities : | |
| 16:36:35 | bauzas | 1/ either you're able to test nova against fake hardware that reproduces the hardware behaviour | |
| 16:36:49 | bauzas | 2/ or you have to provide third-party CI | |
| 16:38:37 | sean-k-mooney | while 2 is preferd it much more overhead btu actull tests that the feature works end to end | |
| 16:38:46 | r-taketn | Does this mean that if we submit third-party CI and comprehensive test results, there is a possibility that they will be merged before the hardware release? | |
| 16:38:55 | sean-k-mooney | no | |
| 16:39:28 | sean-k-mooney | we have strictly applied the requriemetn that hardware is released before its enabeld in the past. we coudl change that | |
| 16:39:34 | sean-k-mooney | but it would eb a break with precedent | |
| 16:39:52 | sean-k-mooney | we also require that any kernel/qemu/libivrt supprot is in a public offcial release | |
| 16:40:02 | sean-k-mooney | so if this requires qemu changes | |
| 16:40:08 | sean-k-mooney | or libvirt | |
| 16:40:23 | sean-k-mooney | those must be in a public offical release formr that upstream proejct before we can enabel it in nova | |
| 16:41:07 | r-taketn | ok, i understood. | |
| 16:41:08 | sean-k-mooney | is arm CCA supported in the kernel, qemu and libvirt today | |
| 16:41:56 | r-taketn | no. LinuxKernel, qemu and libvirt are being developed now. | |
| 16:42:22 | sean-k-mooney | if you want to propose poc patches and prepare them that is fine | |
| 16:42:41 | sean-k-mooney | but we cant merge them until the deps are resolved | |
| 16:42:56 | bauzas | indeed, nothing blocks you to create a feature branch that you could use for your own testing | |
| 16:44:17 | bauzas | what I could suggest you is to come back to us as soon as kernel, QEMU and libvirt versions are released upstream so then we can discuss the alternatives | |
| 16:44:49 | sean-k-mooney | just looking at https://patchwork.kernel.org/project/qemu-devel/cover/20240419155709.318866-2-jean-philippe@linaro.org/ | |
| 16:44:54 | bauzas | but I strongly suggest you to invest a bit of your time into providing a testing kernel framework that could mock any specific hardware | |
| 16:44:56 | sean-k-mooney | it nodes that | |
| 16:45:02 | sean-k-mooney | Enabled support for guest memfd by Xiaoyao Li and Chao Peng [3]. | |
| 16:45:04 | sean-k-mooney | Guest memfd is mandatory for CCA. | |
| 16:45:14 | sean-k-mooney | nova does not supprot memfd currently | |
| 16:45:36 | sean-k-mooney | so there may be other work that is required and we wont knwo that until the qemu/libvirt work is complete | |
| 16:46:26 | r-taketn | I got it. I understood that merging of LinuxKernel, qemu and libvirt are prerequisite. | |
| 16:46:30 | bauzas | which I assume is the reason why r-taketn wants to work on nova | |
| 16:46:57 | sean-k-mooney | well adressing thing like supprotign memfd which is pretty simiple coudl be done independetly | |
| 16:47:29 | sean-k-mooney | we considered addign supprot for it to enabel the manial share attachment feature without hugepages or file backed memory | |
| 16:47:48 | sean-k-mooney | so there may be some work that can be doen without wiating for the hardware. | |
| 16:48:15 | sean-k-mooney | perhaps we can discss this after the meeting if needed | |
| 16:49:07 | opendevreview | Artom Lifshitz proposed openstack/nova master: WIP: Add hw:tpm_secret_security extra spec validation https://review.opendev.org/c/openstack/nova/+/940197 | |
| 16:49:07 | opendevreview | Artom Lifshitz proposed openstack/nova master: WIP: Add hw_tpm_secret_security image property https://review.opendev.org/c/openstack/nova/+/940196 | |
| 16:49:08 | opendevreview | Artom Lifshitz proposed openstack/nova master: WIP: Allow vTPM live migrations for admins https://review.opendev.org/c/openstack/nova/+/925771 | |
| 16:49:50 | r-taketn | ok. I'll rethink the strategy. It would be helpful if you could let us discuss it on the mailing list, etc. | |
| 16:50:34 | sean-k-mooney | you are definetly free too | |
| 16:50:37 | bauzas | sure, r-taketn are you familiar with our release cadence ? | |
| 16:51:10 | sean-k-mooney | this could also be a good topic for a future PTG | |
| 16:51:30 | sean-k-mooney | i know other are also interested in confindcial computing in general | |
| 16:51:53 | r-taketn | I have read and understand the Eproxy Release Schedule. | |
| 16:53:21 | bauzas | r-taketn: the PTG dates for the next release were recently announced | |
| 16:53:47 | bauzas | PTG is a virtual event occuring a couple of days where we usually chat about feature requests | |
| 16:54:13 | bauzas | as sean-k-mooney said, it could be one item worth speaking about | |
| 16:54:41 | bauzas | anyway, we're almost at time, so we need to wrap | |
| 16:54:45 | r-taketn | I would like to attend PTG and discuss it. | |
| 16:55:28 | fwiesel | ls | |
| 16:57:30 | bauzas | r-taketn: then please continue to look at the mailing-list, you'll see some emails about the next steps | |
| 16:58:22 | bauzas | our agenda is pretty free-form, as soon as we draft some ptg etherpad you should be able to add your topic | |
| 16:58:32 | bauzas | ok, that's it for now | |
| 16:58:34 | r-taketn | Ok. Thank you for discussing. | |
| 16:58:41 | bauzas | any other item to cover ? | |
| 16:59:08 | gibi | - | |
| 16:59:21 | bauzas | okay then thanks all | |
| 16:59:26 | opendevmeet | Log: https://meetings.opendev.org/meetings/nova/2025/nova.2025-01-28-16.00.log.html | |
| 16:59:26 | opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/nova/2025/nova.2025-01-28-16.00.txt | |
| 16:59:26 | opendevmeet | Minutes: https://meetings.opendev.org/meetings/nova/2025/nova.2025-01-28-16.00.html | |
| 16:59:26 | opendevmeet | Meeting ended Tue Jan 28 16:59:26 2025 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | |
| 16:59:26 | bauzas | #endmeeting | |
| 16:59:46 | fwiesel | Thanks, and sorry for the noise. | |
| 16:59:56 | masahito | thank you | |
| 17:02:31 | gibi | thanks | |
| 17:12:47 | gibi | bauzas, dansmith, melwitt, sean-k-mooney: I just discovered that we missed the rebuild API action response when we considered the image properties in server details https://review.opendev.org/c/openstack/nova/+/939649/4#message-7d57a602cdd025a52c15c2470091baa6f0ee0340 | |
| 17:12:58 | gibi | would you be OK to amend the spec with this impact? | |
| 17:16:18 | gibi | I need to drop soon but I will read back | |
| 17:21:09 | priteau | bauzas and sean-k-mooney, could you please review this backport? Same as yesterday but for Bobcat: https://review.opendev.org/c/openstack/nova/+/940272 | |
| 17:21:59 | dviroel | gibi: i hit the same issue in https://review.opendev.org/c/openstack/nova/+/938604 - so the same decision should also impact the scheduler_hints spec... | |
| 17:25:53 | bauzas | gibi: I need to reload the context but if you ask for updating a spec post-approval-freeze, that's absolutely fine to me | |
| 17:29:45 | sean-k-mooney | priteau: +2 | |
| 17:53:46 | dansmith | gibi: yep, commented | |
| 18:05:02 | opendevreview | Stephen Finucane proposed openstack/nova master: api: Only check minimum API version https://review.opendev.org/c/openstack/nova/+/940325 | |
| 18:05:11 | stephenfin | sean-k-mooney: took a different approach ^ | |
| 18:06:06 | sean-k-mooney | ya that could work as well. although if your only checkign the min version why is it not positional | |
| 18:06:45 | stephenfin | It effectively is. Do you mean using the forward slash operator? | |
| 18:06:47 | sean-k-mooney | this https://review.opendev.org/c/openstack/nova/+/940325/1/nova/api/openstack/api_version_request.py#300 does not need to be a kw arg | |
| 18:07:17 | stephenfin | I don't understand the question? Are you thinking Python here or Go? :D | |
| 18:07:41 | sean-k-mooney | in python | |
| 18:07:48 | sean-k-mooney | if we always expect to pass version | |
| 18:07:52 | sean-k-mooney | instead of is_supported(req, version=_MIN_API_VERSION): | |
| 18:07:56 | stephenfin | Oh | |
| 18:08:01 | sean-k-mooney | it should be is_supported(req, version): | |
| 18:08:20 | stephenfin | Okay, you were asking why does it take a default | |
| 18:08:21 | sean-k-mooney | you just dont call this if your not enforcing a min right? | |
| 18:08:31 | sean-k-mooney | yes | |
| 18:08:32 | stephenfin | yup, 100%. Good call | |
| 18:08:44 | opendevreview | Stephen Finucane proposed openstack/nova master: api: Only check minimum API version https://review.opendev.org/c/openstack/nova/+/940325 | |
| 18:08:57 | stephenfin | Done. Thanks | |
| 18:09:41 | sean-k-mooney | ok so for make you just using not min | |
| 18:09:47 | sean-k-mooney | ya that works | |
| 18:10:03 | stephenfin | Like I said, if you really want a max check just negate the call | |
| 18:10:25 | sean-k-mooney | well i was just reviewing https://review.opendev.org/c/openstack/nova/+/940325/2/nova/api/openstack/compute/create_backup.py#68 | |
| 18:10:28 | sean-k-mooney | where your doing that | |
| 18:10:52 | stephenfin | I'm nothing if not consistent | |
| 18:11:38 | sean-k-mooney | +1 for now i looked at the first couple of files and ill loop back to it once i have reveiewd the previosu patches | |
| 18:14:49 | sean-k-mooney | sicne your here why did you add a bunch of commans an reflow things in https://review.opendev.org/c/openstack/nova/+/936369/7/nova/api/validation/parameter_types.py | |