| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2026-04-07 | |||
| 21:36:11 | melwitt | yeah .. that would work I think | |
| 21:36:30 | sean-k-mooney | you coudl also upgrae to that by backfilling the ACL | |
| 21:36:56 | melwitt | honestly that seems easier because then the service project thing doesn't come up | |
| 21:37:33 | sean-k-mooney | although well it kind of does but only in the sense that what ever auth cred we are usign to talk to it need to be one form our config | |
| 21:37:51 | sean-k-mooney | but just lookign at master for a second | |
| 21:37:53 | sean-k-mooney | https://opendev.org/openstack/barbican/src/branch/master/barbican/common/policies/secrets.py#L19-L26 | |
| 21:38:08 | sean-k-mooney | rule:secret_project_admin | |
| 21:38:17 | melwitt | yeah but I mean if we do it by giving the nova user access via acl, then it's never open to the service project right | |
| 21:38:37 | sean-k-mooney | i asumem that is someone wiht the admin role that has a project scoped token for that project right | |
| 21:38:58 | melwitt | I think that's what that means, yes | |
| 21:39:06 | sean-k-mooney | oh well there may or may not be a shared service project | |
| 21:39:20 | sean-k-mooney | we do that in devstack but in our down stream we dont i belive | |
| 21:39:28 | melwitt | true, but the "common" deployment is done that way | |
| 21:39:43 | sean-k-mooney | it woudl allow use to restict ti to just the nova user however | |
| 21:39:52 | sean-k-mooney | if ther was a shared service proejct so that still better | |
| 21:41:04 | sean-k-mooney | well not nessicarly "beter" then owned by nova in genreal jsut better then "accsabel by anyone in the service project" | |
| 21:41:38 | melwitt | right | |
| 21:41:57 | melwitt | it's the open-to-the-service-project that seems a bit too out there | |
| 21:42:34 | sean-k-mooney | right. so looking at barbican base policy they do impmente proejct scoped admin to some degree | |
| 21:42:49 | sean-k-mooney | but that really global admin | |
| 21:43:14 | sean-k-mooney | so today if an admin added themselve to a end users project the shoudl be bale to live mgigrate | |
| 21:43:32 | sean-k-mooney | provide we just dont block it in the api and try to download the secret when needed | |
| 21:43:46 | sean-k-mooney | i.e with teh defualt "user" policy | |
| 21:44:04 | sean-k-mooney | what "deployment" or "delegated" what ever we want to call the acl approch gives | |
| 21:44:13 | melwitt | yeah exactly. it is possible for project admin today | |
| 21:44:17 | sean-k-mooney | is the ablity to skip adding yourself to the end users policy | |
| 21:44:47 | sean-k-mooney | *end users project | |
| 21:44:53 | sean-k-mooney | jsut to do the live migration | |
| 21:45:25 | sean-k-mooney | so its a net win still be but the security posture is mostly the same as user or host | |
| 21:45:53 | melwitt | yeah. it feels like it makes more sense too in a way. like more intuitive | |
| 21:46:30 | sean-k-mooney | i think this also means that an admin coudl also jsut live migrate any vm with the user policy if they just add the acl to the relevent secret right? | |
| 21:46:35 | sean-k-mooney | for there user? | |
| 21:46:40 | melwitt | I really don't want to have to migrate 'deployment' secrets though, ugh. | |
| 21:47:01 | sean-k-mooney | well you dont have to move them | |
| 21:47:20 | sean-k-mooney | that the nice thign about deployment you jsut get them form barbican in pre live migrate | |
| 21:47:27 | sean-k-mooney | there is no copyign right. | |
| 21:47:28 | melwitt | yes you can with acl also. a bit more code is needed to enable 'user' live migration and I have them proposed | |
| 21:47:59 | sean-k-mooney | by migrate deployment secret did you mean add the acl? | |
| 21:48:08 | sean-k-mooney | or did you mean move them during live migrate? | |
| 21:48:21 | sean-k-mooney | or i guess copy them to a new secret | |
| 21:48:31 | sean-k-mooney | but that woudl be on resize right | |
| 21:48:45 | melwitt | yeah but I mean if we wanted to do the user + acl for nova user thing, taking the nova user secret and creating a user secret and copying the passphrase over and adding the acl, I dunno. mess | |
| 21:49:13 | sean-k-mooney | oh your sayign supprotign the 4th policy | |
| 21:49:19 | sean-k-mooney | fo ading the nova user by acl | |
| 21:49:20 | melwitt | for potentially already existing 'deployment' | |
| 21:49:29 | melwitt | secrets | |
| 21:49:39 | sean-k-mooney | ah well we dont have that yet do we? | |
| 21:49:46 | sean-k-mooney | i tought that was not merged | |
| 21:49:55 | melwitt | we do have the secret generation but not the live migration | |
| 21:50:01 | sean-k-mooney | ah ok | |
| 21:50:14 | sean-k-mooney | well if we atned to suprpot it its feeld like a 4th policy | |
| 21:50:42 | sean-k-mooney | but i htink as you suggested talking to the barbican folks at the ptg would be a good next step | |
| 21:50:48 | melwitt | yeah.. that would be easier to not have to deal with it. and then let it stay open to the service project? I dunno. just rambling | |
| 21:50:53 | sean-k-mooney | to confirm that the acls are actully workign as we think they do | |
| 21:51:25 | sean-k-mooney | melwitt: well if its a new policy we can recommend that you resize to delegated for better security or something | |
| 21:51:54 | sean-k-mooney | where deploymene i "nova owned secte" adn delegated is "user owned secreate with nova acl" | |
| 21:52:08 | melwitt | yeah. that would be much less pain | |
| 21:52:19 | melwitt | ++ | |
| 21:52:23 | sean-k-mooney | in anycase i think we shoudl finsih the deploymetn live migration supprot first | |
| 21:52:35 | melwitt | yeah, I agree | |
| 21:52:39 | sean-k-mooney | then maybe tack this on if folks agree | |
| 21:52:58 | melwitt | the way I have it is I put 'user' ahead of 'deployment' since 'user' support is a subset of 'deployment' | |
| 21:53:38 | sean-k-mooney | ya host was the most invasive one | |
| 21:53:43 | melwitt | much smaller change than 'deployment' bc 'deployment' ultimately needs to be able to do secret conversions for resizes | |
| 21:53:47 | sean-k-mooney | as all the resed didnt need rpc/obejct changes | |
| 21:54:18 | sean-k-mooney | right ya i see | |
| 21:54:46 | sean-k-mooney | its not alot diffent for the acl approch as you woudl still need to add/remove it when you change form user | |
| 21:54:52 | sean-k-mooney | but that a singel api call | |
| 21:55:04 | sean-k-mooney | no need to copy the data and reupload it | |
| 21:55:05 | melwitt | yeah, I don't think it would be much to add | |
| 21:55:57 | sean-k-mooney | all fo this falls apart if acls dont work that way but that seams to be what those spec imply | |
| 21:57:06 | sean-k-mooney | kilo era features with "This ACL documentation is work in progress and may change in near future." | |
| 21:57:38 | sean-k-mooney | make me causiously optimistic | |
| 21:57:47 | melwitt | they seem to work how we think, at least in my unexpert testing in devstack. I also used the acl in the 'user' live migration tempest tests I wrote and that works too | |
| 22:00:21 | sean-k-mooney | ok im going to call it a night o/ | |
| 22:00:52 | melwitt | seeya o/ | |
| 22:01:55 | opendevreview | sean mooney proposed openstack/nova master: Fix unified limits to include all resource types https://review.opendev.org/c/openstack/nova/+/975872 | |
| 22:01:55 | opendevreview | sean mooney proposed openstack/nova master: Add regression test for unified limits resource bug https://review.opendev.org/c/openstack/nova/+/975859 | |
| 22:03:14 | sean-k-mooney | i dont know if i resoved all the comments on that but i just pushed what i had ill take a look at it again tomorrow | |
| 22:08:10 | melwitt | ack | |
| #openstack-nova - 2026-04-08 | |||
| 00:04:23 | opendevreview | Merged openstack/nova master: db: add indexes for source/dest migrations https://review.opendev.org/c/openstack/nova/+/958556 | |
| 07:20:59 | opendevreview | ChungWon Lee proposed openstack/nova master: Fix port remain while error on update port with multi network https://review.opendev.org/c/openstack/nova/+/983672 | |
| 07:57:08 | opendevreview | Fabian Wiesel proposed openstack/nova master: conductor: reset placement and auth clients after fork https://review.opendev.org/c/openstack/nova/+/983676 | |
| 08:34:28 | opendevreview | Fabian Wiesel proposed openstack/nova master: conductor: reset placement and auth clients after fork https://review.opendev.org/c/openstack/nova/+/983676 | |
| 09:18:35 | gibi | melwitt: dansmith: sean-k-mooney: here is the result for a 13 measurement on the PCI device tpool proxy situation https://paste.openstack.org/show/bKHhndSgMIVJtRn1HQLe/ | |
| 09:19:06 | gibi | I see some runtime increase but the timing is pretty noisy | |
| 09:19:50 | gibi | https://www.pasteboard.co/w-LCl8LzsgIk.png | |
| 09:23:49 | gibi | the minimum run times are increasing I would say | |
| 09:36:03 | MaxLamprecht[m] | gibi: can you share the libvirt version you have running? | |
| 09:57:04 | opendevreview | Takashi Kajinami proposed openstack/nova-specs master: libvirt: AMD SEV-SNP support https://review.opendev.org/c/openstack/nova-specs/+/983376 | |
| 09:59:43 | opendevreview | Takashi Kajinami proposed openstack/nova-specs master: libvirt: AMD SEV-SNP support https://review.opendev.org/c/openstack/nova-specs/+/983376 | |
| 10:01:30 | opendevreview | Takashi Kajinami proposed openstack/nova-specs master: libvirt: AMD SEV-SNP support https://review.opendev.org/c/openstack/nova-specs/+/983376 | |
| 10:30:22 | gibi | MaxLamprecht[m]: 10.0.0-2ubuntu8.12 | |
| 10:48:46 | MaxLamprecht[m] | The increase of the minimum run time sounds similar to my reported finding. I assume that if you are updating to libvirt > 10.5 this constant increase is gone. | |
| 11:01:05 | gibi | hm, interesting. That would suggest that the actual increase is due to libvirt and not due to nova itself | |
| 11:08:30 | gibi | so if that is a theory then that suggests something accumlates on the libvirt side and a libvirt restart without a compute restart could clear it | |
| 11:09:14 | gibi | MaxLamprecht[m]: do you have a link to the bug / bugfix in libvirt 10.5 that supposed to help? | |
| 11:10:10 | gibi | sorry I saw it in the bug | |
| 11:10:16 | gibi | thanks for adding it there | |
| 11:10:36 | gibi | it seems we both wrote a comment to that bug around the same time | |