Earlier  
Posted Nick Remark
#openstack-nova - 2025-03-28
14:48:02 opendevreview Rajesh Tailor proposed openstack/nova stable/2025.1: Fix case sensitive comparison https://review.opendev.org/c/openstack/nova/+/945843
16:10:44 opendevreview Balazs Gibizer proposed openstack/nova master: DNM:Refactor OTU https://review.opendev.org/c/openstack/nova/+/945856
17:21:38 opendevreview Dan Smith proposed openstack/nova master: Invalidate PCI-in-placement cached RPs during claim https://review.opendev.org/c/openstack/nova/+/944149
17:21:38 opendevreview Dan Smith proposed openstack/nova master: Support "one-time-use" PCI devices https://review.opendev.org/c/openstack/nova/+/943816
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

Earlier   Later