| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2026-04-07 | |||
| 17:37:48 | sean-k-mooney | ack im currnetly comparing in my cybrog/pci groupign env. ill leave it alone for not but if you dong see anygint i can maybe run ~50-80 vms | |
| 17:39:00 | sean-k-mooney | i belive i have 2 sriov capable nic on this host and i shoudl barely have enough disk/ram but i havent really pushed this host to find its limits | |
| 17:44:42 | gibi | I don't see any timing data difference between 10VMs without PCI usage and 10 VMs with one VF usage each (both cases the VMs are in shutoff) | |
| 17:45:31 | gibi | so what I will do I will keep the 10 VMs with one VF each,take a GMR and then let the periodic run every 10 seconds during the night | |
| 17:47:59 | sean-k-mooney | hum im not sure what runing vs not would cause in this context | |
| 17:48:34 | sean-k-mooney | techinaly that does change the retivial of mac adresses for VFs | |
| 17:49:01 | sean-k-mooney | i.e. if livbirt is restart after the vf is passed to the vm it may not see the mac | |
| 17:49:34 | sean-k-mooney | but did the bug say it was realted to runign/active vms or are you just leaving them stop to reduces load | |
| 17:49:37 | gibi | I simply want to avoid the cpu usage noise of the 10 VMs running | |
| 17:49:44 | sean-k-mooney | ah ok | |
| 17:49:55 | sean-k-mooney | you could start them and then pause them | |
| 17:49:57 | gibi | it is non 0 even with cirros | |
| 17:50:01 | gibi | sure | |
| 17:50:03 | gibi | that is better | |
| 17:50:25 | sean-k-mooney | but i suspect we wont see much of a delta on the perodic althoug hif we do it would be an interesting datapoint i guess | |
| 18:17:33 | gibi | a quick look in two GMRs ~5 minutes distance I don't see increasing number of Green Threads or Threads reported. | |
| 18:25:59 | gibi | OK. This is the starting state of my measurement setup for the night https://paste.openstack.org/show/b96mgBQpguw6KUseBAgZ/ | |
| 18:34:26 | melwitt | awesome gibi | |
| 20:10:24 | melwitt | dansmith: fyi potential cross-project PTG topic re: barbican secrets https://etherpad.opendev.org/p/nova-2026.2-ptg#L90 cc Uggla sorry if I put the text in the wrong location in the etherpad, feel free to move it | |
| 20:28:00 | dansmith | melwitt: ack, not sure that needs to be a cross-project session really, but cool.. I also didn't realize you were worried about the deployment side of the ownership thing, more the user one | |
| 20:28:11 | dansmith | but good point that neutron would have access to those keys | |
| 20:28:19 | dansmith | unless nova could change the ACL itself | |
| 20:29:20 | melwitt | dansmith: my brain started on user and then the realization about service hit. but yeah nova can change the ACL itself as far as I know | |
| 20:30:02 | melwitt | I thought you had suggested we talk to ppl who know more about barbican so I put it cross-project | |
| 20:30:20 | melwitt | it does suck that there's no way to do ACLs through castellan. not sure if that's by design | |
| 20:31:12 | melwitt | I guess maybe not all key managers support ACLs | |
| 20:33:31 | dansmith | ack | |
| 20:56:44 | sean-k-mooney | melwitt: by the way i belive there as a specic commit possibel as part fo there srbac work that change teh secrte to be owned by the proejct | |
| 20:57:36 | sean-k-mooney | melwitt: i dont exactly know why i feel tha tway but i think we talksed about it before | |
| 20:58:22 | melwitt | sean-k-mooney: I wondered if that could be a possibility. I'll take another gander | |
| 20:58:30 | sean-k-mooney | i.e. the fact that is not only accable by the user is someitng that i was vaugly aware of an that it was not alwasy that way | |
| 21:00:40 | melwitt | as far as I could find it goes down to the model and object level, so always been that way | |
| 21:01:15 | melwitt | (this was just me looking in the code) | |
| 21:01:30 | dansmith | yeah I really thought we were told that it was specific to the user and not the project | |
| 21:02:12 | sean-k-mooney | melwitt: maybe https://opendev.org/openstack/barbican/commit/cd9b0ba9f0b4606193858d3cf05acd413a66ba1e | |
| 21:02:34 | sean-k-mooney | they use to enforce _SECRET_CREATOR = "user_id:%(target.secret.creator_id)s" | |
| 21:03:09 | sean-k-mooney | ... storybaord 2010235 has more info | |
| 21:03:38 | sean-k-mooney | huh its actully working https://storyboard.openstack.org/#!/story/2010235 | |
| 21:03:47 | sean-k-mooney | i guess the bots doen know about story board | |
| 21:05:37 | sean-k-mooney | ya so in https://opendev.org/openstack/barbican/commit/cd9b0ba9f0b4606193858d3cf05acd413a66ba1e the allowed project member not jsut teh orgial secreat creator to decrpte the secrete adn basiclly mange it | |
| 21:06:24 | melwitt | lol storyboard | |
| 21:06:30 | sean-k-mooney | without the need for acls so that proably shoudl ahve at least had a release note... or a doc update.... | |
| 21:07:20 | sean-k-mooney | https://review.opendev.org/c/openstack/barbican/+/853680 apprently that was aslo cherry-picked which is qustionable | |
| 21:07:24 | melwitt | yeah that's a pretty major change | |
| 21:07:34 | sean-k-mooney | although i coudl eb misreading those polices but i dont think i am | |
| 21:08:00 | dansmith | but these are API policies - doesn't barbican also have a more robust internal ACL system? | |
| 21:08:03 | dansmith | I guess I thought that | |
| 21:08:12 | dansmith | is what we were talking about here and not just API policy | |
| 21:08:27 | melwitt | I guess the old rule had rule:secret_project_admin which allows project admin also | |
| 21:08:34 | sean-k-mooney | hum actully on gerrit i think i might be https://review.opendev.org/c/openstack/barbican/+/853680/9/barbican/common/policies/secrets.py#72 | |
| 21:09:15 | melwitt | secrets are not as secret as I had thought :P | |
| 21:09:26 | sean-k-mooney | im not familar with rule:secret_is_not_private | |
| 21:09:59 | melwitt | that's the project_access thing. project_access=false=private. at least that's how it is today | |
| 21:10:09 | sean-k-mooney | ah | |
| 21:10:33 | sean-k-mooney | so seperatly form the acl you can mark it as prive to a user or public to the project | |
| 21:11:05 | sean-k-mooney | i assume acls were an evoltion of that with more granualatiy or someitng in later release | |
| 21:11:08 | melwitt | no that is the ACL. i.e. if you want to change it, it's a PUT to the /acl API | |
| 21:11:28 | dansmith | so the api policy defines the default but I can still ACL individual secrets however I want? | |
| 21:12:11 | melwitt | as far as I can tell the default is hard-coded, I don't think you can change it | |
| 21:12:16 | melwitt | *don't think you can change the default | |
| 21:12:33 | melwitt | and you can't create a secret to have project_access=false from the get go | |
| 21:12:34 | sean-k-mooney | https://docs.openstack.org/barbican/latest/api/reference/acls.html | |
| 21:12:53 | sean-k-mooney | so apprenlty the acl is on tdefien on indeivual secrets but the contienr the sectes are contied in | |
| 21:13:10 | sean-k-mooney | it feels like this is not fully baked based on teh documantion warning | |
| 21:14:37 | sean-k-mooney | https://docs.openstack.org/api-guide/key-manager/acls.html#default-acl | |
| 21:14:37 | melwitt | yeah... kinda also why I was thinking cross-project at the ptg, to just get a sanity check from barbican experts if they are out there | |
| 21:15:02 | sean-k-mooney | { | |
| 21:15:04 | sean-k-mooney | "read":{ | |
| 21:15:06 | sean-k-mooney | "project-access": true | |
| 21:15:08 | sean-k-mooney | } | |
| 21:15:10 | sean-k-mooney | } | |
| 21:15:19 | sean-k-mooney | so that apprently the default os i guess whne they added acls it change the behvior | |
| 21:15:45 | melwitt | ok so you are saying before ACLs even existed, it was like private secrets? | |
| 21:17:13 | melwitt | vtpm was added in the victoria release which was in 2020 | |
| 21:17:37 | sean-k-mooney | im not sure | |
| 21:17:43 | sean-k-mooney | bu tjsut skiming ther eapi ref | |
| 21:17:56 | sean-k-mooney | i think if we anted to chagne teh bhvior we would need 3 calls minium | |
| 21:18:04 | sean-k-mooney | 1 to create a metadata only secrete | |
| 21:18:09 | sean-k-mooney | then to apply the acl to it | |
| 21:18:15 | sean-k-mooney | and finaly to upload the data | |
| 21:18:47 | sean-k-mooney | i would assume we are not doing that today | |
| 21:19:12 | melwitt | yeah that's exactly what I thought we would have to do and no we are not doing that today | |
| 21:19:18 | sean-k-mooney | so when we are creatign the "user" secreat its likely project scoped | |
| 21:19:34 | melwitt | secrets in nova have always been create with the default acl, so have always been open to project | |
| 21:20:16 | melwitt | I don't know why I thought they were private to a user :( | |
| 21:21:54 | sean-k-mooney | so its the secret:decrypt | |
| 21:22:00 | sean-k-mooney | polyc that we care about rahter then get | |
| 21:22:07 | sean-k-mooney | get is just the metadata | |
| 21:22:07 | melwitt | correct | |
| 21:22:19 | melwitt | yes | |
| 21:23:26 | melwitt | man the test_resize_reschedule_uses_host_lists_3_fails unit test is going crazy in CI | |
| 21:23:48 | sean-k-mooney | https://opendev.org/openstack/barbican/blame/commit/661386a517fac2f81d6b35706dd360b045955c3f/barbican/common/policies/secrets.py#L21 | |
| 21:24:03 | sean-k-mooney | so that acl rules has been there for at least 10 years | |
| 21:24:47 | sean-k-mooney | so in effect they have never been user scoped unless you change the acl | |
| 21:24:58 | melwitt | I don't think so right because of this https://opendev.org/openstack/barbican/src/commit/661386a517fac2f81d6b35706dd360b045955c3f/barbican/common/policies/base.py#L50-L52 | |
| 21:25:14 | melwitt | oh wait that's not decrypt | |
| 21:25:49 | sean-k-mooney | righ if you look at https://opendev.org/openstack/barbican/blame/commit/661386a517fac2f81d6b35706dd360b045955c3f/barbican/common/policies/secrets.py#L21 | |
| 21:26:03 | sean-k-mooney | that has the 'rule:secret_acl_read' rule alaready | |
| 21:26:03 | melwitt | https://opendev.org/openstack/barbican/src/commit/661386a517fac2f81d6b35706dd360b045955c3f/barbican/common/policies/base.py#L53-L55 | |
| 21:26:30 | melwitt | if I read that right it was allow project admin, project observer, project creator | |