| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2025-03-28 | |||
| 17:21:39 | opendevreview | Dan Smith proposed openstack/nova master: Add one-time-use devices docs and reno https://review.opendev.org/c/openstack/nova/+/944262 | |
| 17:21:39 | opendevreview | Dan Smith proposed openstack/nova master: DNM: Test nova with placement alloc fix https://review.opendev.org/c/openstack/nova/+/945626 | |
| 17:26:16 | opendevreview | Artom Lifshitz proposed openstack/nova master: Add hw_tpm_secret_security image property https://review.opendev.org/c/openstack/nova/+/940196 | |
| 17:26:16 | opendevreview | Artom Lifshitz proposed openstack/nova master: Add hw:tpm_secret_security extra spec validation https://review.opendev.org/c/openstack/nova/+/940197 | |
| 17:26:17 | opendevreview | Artom Lifshitz proposed openstack/nova master: TPM: migrate legacy instances to new security policy https://review.opendev.org/c/openstack/nova/+/942501 | |
| 17:26:17 | opendevreview | Artom Lifshitz proposed openstack/nova master: TPM: support booting instances with `user` secret security https://review.opendev.org/c/openstack/nova/+/942502 | |
| 17:26:18 | opendevreview | Artom Lifshitz proposed openstack/nova master: TPM: support instances with `host` secret security https://review.opendev.org/c/openstack/nova/+/941795 | |
| 17:26:18 | opendevreview | Artom Lifshitz proposed openstack/nova master: [WIP] TPM: support live migration of `host` secret security https://review.opendev.org/c/openstack/nova/+/941483 | |
| 17:26:19 | opendevreview | Artom Lifshitz proposed openstack/nova master: WIP: TPM: support instances with `deployment` secret security https://review.opendev.org/c/openstack/nova/+/942021 | |
| 17:26:20 | opendevreview | Artom Lifshitz proposed openstack/nova master: WIP: Allow vTPM live migration for `deployment` secret security https://review.opendev.org/c/openstack/nova/+/925771 | |
| 17:45:27 | opendevreview | Artom Lifshitz proposed openstack/nova master: TPM: migrate legacy instances to new security policy https://review.opendev.org/c/openstack/nova/+/942501 | |
| 17:45:27 | opendevreview | Artom Lifshitz proposed openstack/nova master: TPM: support booting instances with `user` secret security https://review.opendev.org/c/openstack/nova/+/942502 | |
| 17:45:28 | opendevreview | Artom Lifshitz proposed openstack/nova master: TPM: support instances with `host` secret security https://review.opendev.org/c/openstack/nova/+/941795 | |
| 17:45:28 | opendevreview | Artom Lifshitz proposed openstack/nova master: [WIP] TPM: support live migration of `host` secret security https://review.opendev.org/c/openstack/nova/+/941483 | |
| 17:45:29 | opendevreview | Artom Lifshitz proposed openstack/nova master: WIP: TPM: support instances with `deployment` secret security https://review.opendev.org/c/openstack/nova/+/942021 | |
| 17:45:29 | opendevreview | Artom Lifshitz proposed openstack/nova master: WIP: Allow vTPM live migration for `deployment` secret security https://review.opendev.org/c/openstack/nova/+/925771 | |
| 20:08:11 | gboutry | sean-k-mooney: back on this nova issue, still nowhere close to a resolution. I've opened a bug on upstream eventlet, but not sure things will progress more on this end | |
| 20:09:07 | gboutry | sean-k-mooney: I've used weakref.finalizer to add a callback on admin_client.base_client finalization, and it gets finalized inside the active greenthread... but admin_client itself does not get finalized before much later... | |
| 20:10:05 | gboutry | For reference, I'm talking about this specific admin_client: https://opendev.org/openstack/nova/src/commit/98226b60f3fe7b20e8d7f208c12f8d0086cd83d0/nova/network/neutron.py#L1216 | |
| #openstack-nova - 2025-03-29 | |||
| 12:02:17 | opendevreview | Yaguang Tang proposed openstack/nova stable/2023.2: Fix device type when booting from ISO image https://review.opendev.org/c/openstack/nova/+/945903 | |
| 14:23:04 | opendevreview | Artom Lifshitz proposed openstack/nova master: [WIP] TPM: support live migration of `host` secret security https://review.opendev.org/c/openstack/nova/+/941483 | |
| 14:23:04 | opendevreview | Artom Lifshitz proposed openstack/nova master: WIP: TPM: support instances with `deployment` secret security https://review.opendev.org/c/openstack/nova/+/942021 | |
| 14:23:05 | opendevreview | Artom Lifshitz proposed openstack/nova master: WIP: Allow vTPM live migration for `deployment` secret security https://review.opendev.org/c/openstack/nova/+/925771 | |
| #openstack-nova - 2025-03-30 | |||
| 02:32:27 | opendevreview | Artom Lifshitz proposed openstack/nova master: [WIP] TPM: support live migration of `host` secret security https://review.opendev.org/c/openstack/nova/+/941483 | |
| 02:32:27 | opendevreview | Artom Lifshitz proposed openstack/nova master: WIP: TPM: support instances with `deployment` secret security https://review.opendev.org/c/openstack/nova/+/942021 | |
| 02:32:28 | opendevreview | Artom Lifshitz proposed openstack/nova master: WIP: Allow vTPM live migration for `deployment` secret security https://review.opendev.org/c/openstack/nova/+/925771 | |
| #openstack-nova - 2025-03-31 | |||
| 06:52:07 | opendevreview | Zhang Hua proposed openstack/nova stable/2024.1: Fix deepcopy usage for BlockDeviceMapping in get_root_info https://review.opendev.org/c/openstack/nova/+/926696 | |
| 06:52:08 | opendevreview | Zhang Hua proposed openstack/nova stable/2024.1: Fix device type when booting from ISO image https://review.opendev.org/c/openstack/nova/+/945816 | |
| 13:10:25 | zigo | sean-k-mooney: Sorry for I didn't write your first name correctly on my message to the list. :/ | |
| 13:11:04 | zigo | And thanks a lot for your reply. | |
| 13:11:20 | zigo | There's still things I don't understand. | |
| 13:11:55 | zigo | Manila has multiple modes, one is the "generic" one that I used to use, and the other one that has to be used for CephFS. | |
| 13:12:14 | zigo | When you write that I have "nothing to do", I suppose that is, compared to the non-generic mode, right? | |
| 13:13:24 | sean-k-mooney | zigo: it fine i dont mind i technically didnt either its "seán" not "sean" but typeing the foda over the a often breaks things :) | |
| 13:14:23 | sean-k-mooney | zigo: when i say there is noghting to do i mean nova should not need to care how manilla is configured | |
| 13:14:54 | zigo | Yeah, but I need to somehow teach my management software to configure Manila for virtio-fs... :) | |
| 13:14:55 | sean-k-mooney | its just useing the info form the share export/attachment (whatever its called in manilas api) | |
| 13:15:14 | sean-k-mooney | manila does nto need special config | |
| 13:15:45 | sean-k-mooney | the way this is working is we are attachign the manila share to the compute host and then using virtio-fs to passthough that "local" filestytem to the vm | |
| 13:16:20 | zigo | Yeah, got that point. | |
| 13:16:57 | zigo | Though, for example, in manila.conf's share_driver, what should I write? | |
| 13:16:58 | sean-k-mooney | for cephfs the compute node need to access to the ceph cluster for that to work. with the generic driver the comptue node wound need to have network connectivity with the vm that runing the nfs server | |
| 13:17:48 | sean-k-mooney | zigo: Uggla can correct men if im wrong but it should not need any config changes form using the backend without this feature | |
| 13:20:18 | sean-k-mooney | zigo: as far as im aware, your installer should not need to do any config on the manilla side and the only config change needed on nova are the manilla keystone auth parmaters https://docs.openstack.org/nova/latest/configuration/config.html#manila | |
| 13:21:08 | sean-k-mooney | we have only one manila specific option https://docs.openstack.org/nova/latest/configuration/config.html#manila.share_apply_policy_timeout | |
| 13:24:34 | carloss | zigo: ++ on sean-k-mooney's info. No additional configuration is needed in Manila. You would only need to have the backend properly configured as in any deployment other deployment, create a share and provide it during the nova attachment process, then nova and manila will do the rest for you (creating access rules, locking the share, locking the access rules and so on) | |
| 13:26:11 | sean-k-mooney | if your using the generic driver the main limiation is the share network needs to be routeable form the compute nodes | |
| 13:26:35 | sean-k-mooney | basically meaning it should be a neutron external network unlss floating ips work with manilla? | |
| 13:27:18 | Uggla | Yes only a manila section like the one from cinder but with name [manila] | |
| 13:28:15 | Uggla | so nova could get the enpoint + cred to access manila. | |
| 13:28:51 | sean-k-mooney | Uggla: i notcied we dont seam to have a tempest job for this in nova yet | |
| 13:29:03 | sean-k-mooney | or at least i didnt see this enabled in any of our exsitign jobs | |
| 13:29:10 | sean-k-mooney | do you have patches for that still pending? | |
| 13:29:42 | Uggla | yep I know and I'm guilty about it. I worked on them, but did not complete them yet. | |
| 13:29:49 | sean-k-mooney | it would be nice ot test cephfs in our ceph job and the generic driver with lvm in one of the ohters | |
| 13:29:51 | sean-k-mooney | ack | |
| 13:30:41 | sean-k-mooney | Uggla: well you did a lot last cycle. i was more asking to see if we could provide a refence to zigo of devstack cofniguration for ceph and nfs via cinder lvm | |
| 13:30:52 | sean-k-mooney | so they could take a look at how it works | |
| 13:31:08 | Uggla | sean-k-mooney, but there are discussion to have this effort done by the manila team. | |
| 13:31:22 | Uggla | or part of the effort. | |
| 13:31:36 | sean-k-mooney | it could be but we should be testing it in our jobs too | |
| 13:32:26 | Uggla | Of course I can provide zigo how to configure with devstack, so he could transpose to his configuration. | |
| 13:32:27 | sean-k-mooney | i dont think we need new jobs in nova just our existing jobs shoudl be tweeked | |
| 13:32:52 | sean-k-mooney | Uggla: ya i think that would help | |
| 13:33:25 | Uggla | btw there is a fn job with the sdk which is doint minimal testing against tempest. | |
| 13:33:50 | Uggla | s/doint/doing | |
| 14:21:10 | zigo | sean-k-mooney: If I'm going to use virtio-fs, that's precisely because I do not want to use the generic driver. | |
| 14:23:09 | zigo | What I don't get though, is if I'm using the "normal" cephfs driver, I do not want my users to be able to use cephfs direct connection from their VMs. | |
| 14:23:22 | zigo | For us, the Ceph backplane is *not* accessible from the VMs. | |
| 14:23:30 | zigo | (or purpose, for security reasons). | |
| 14:23:36 | zigo | So is there a way to desactivte it? | |
| 14:28:40 | zigo | Uggla: ^ | |
| 14:29:19 | sean-k-mooney | zigo: you can deploy your ceph so that there is no routeablity form the vm subnets | |
| 14:29:31 | sean-k-mooney | but there is routablity on the compute nodes | |
| 14:29:34 | zigo | That's the case already. :) | |
| 14:30:32 | zigo | But then, the API will be still available, I was hoping for it to say "404: cephfs API not activated, please use virtio-fs instead" or something ... | |
| 14:32:06 | sean-k-mooney | no | |
| 14:32:14 | sean-k-mooney | because manilla does not know about virtiofs | |
| 14:32:31 | sean-k-mooney | that an internal implemation detail of nova (sepcrically the libvirt driver) | |
| 14:33:45 | sean-k-mooney | zigo: i belive there might be a way to limit what info is shown to nova (via the service role) and the user (member/reader) | |
| 14:33:51 | sean-k-mooney | on the manilla side | |
| 14:42:07 | opendevreview | Dan Smith proposed openstack/nova master: Invalidate PCI-in-placement cached RPs during claim https://review.opendev.org/c/openstack/nova/+/944149 | |
| 14:42:07 | opendevreview | Dan Smith proposed openstack/nova master: Support "one-time-use" PCI devices https://review.opendev.org/c/openstack/nova/+/943816 | |
| 14:42:08 | opendevreview | Dan Smith proposed openstack/nova master: Add one-time-use devices docs and reno https://review.opendev.org/c/openstack/nova/+/944262 | |
| 14:42:08 | opendevreview | Dan Smith proposed openstack/nova master: DNM: Test nova with placement alloc fix https://review.opendev.org/c/openstack/nova/+/945626 | |
| 14:48:53 | dansmith | gibi: are you intending to hold off approving/merging OTU until after discussion at the PTG? | |
| 14:49:19 | sean-k-mooney | are there open desgin decisions ? | |
| 14:49:54 | sean-k-mooney | i.e. that need dicsussion at the ptg | |
| 14:49:58 | dansmith | not that I'm aware of, and the spec is merged, I just had the thought that maybe gibi was expecting to wait | |
| 14:50:01 | sean-k-mooney | or is it just normal code review that needed | |
| 14:50:07 | dansmith | just normal review, I think | |
| 14:50:12 | sean-k-mooney | ack | |
| 14:50:23 | dansmith | it's on the PTG for discussion, but TBH i was hoping to have it merged before then | |
| 14:50:32 | dansmith | since I'll be out for part of it (and the week after) | |
| 14:50:33 | sean-k-mooney | i personally have not had time to loop back to the impl much | |
| 14:50:57 | gibi | dansmith: I think we can progress with the normal code review. Right now I don't see any open questions on the spec level | |
| 14:50:59 | sean-k-mooney | but i didnt have any huge concern with the approch that was nto adressed in the spec | |
| 14:51:30 | dansmith | gibi: ack, I agree, I just realized I wasn't sure what others were actually thinking | |
| 14:51:42 | sean-k-mooney | dansmith: the only thing that comes to mind really are your expermient with using virt-rng ot try and test this in ci | |
| 14:52:06 | dansmith | sean-k-mooney: I've already got the images modified on vexx, and was planning to try to work on that next sprint | |