| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2026-04-03 | |||
| 13:39:03 | TheJulia | yeah, because of all the things around shim packaging we've seen those names change/evolve a lot over the years, that should really be in bindep :\ | |
| 13:39:11 | TheJulia | ... and LP doesn't load for me today. Joy! | |
| 13:40:00 | sean-k-mooney | hum same | |
| 13:40:36 | sean-k-mooney | it might just be very slow it did fineally load partly with a timeout error | |
| 13:41:30 | TheJulia | took close to 90 seconds on my end, but yeah, did finally load | |
| 13:42:08 | TheJulia | 30+ seconds to just sort the bug list, awesome! | |
| 13:42:34 | sean-k-mooney | shall i file it or are you on it | |
| 13:42:39 | TheJulia | I'll do it | |
| 13:42:46 | sean-k-mooney | cool | |
| 13:43:38 | sean-k-mooney | im seeing up a dev env badsed on the patch jay created so if i get time to look at the startup performance between now and the ptg i have a place to test things out | |
| 13:43:50 | sean-k-mooney | then you on im goign to enjoy the day off :) | |
| 13:50:42 | TheJulia | enjoy! | |
| 14:17:46 | TheJulia | gibi: I don't see any issue with your tls socket change, that being said it looks like somewhere the job setup for graphical console in ironic ci fell down or got lost, I'm going to sync up with stevebaker next week and we'll get it on the top of our list to sort out next week. | |
| 15:55:51 | Uggla | FYI I have booked the PTG slots here: https://ptg.opendev.org/ptg.html. This will happen mostly in Liberty room. Note this is currently draft, I will arrange when I'll be back from PTO. | |
| 22:56:10 | opendevreview | melanie witt proposed openstack/nova master: TPM: fixup for bump service version documentation https://review.opendev.org/c/openstack/nova/+/978836 | |
| 22:56:11 | opendevreview | melanie witt proposed openstack/nova master: TPM: support live migration of `user` secret security https://review.opendev.org/c/openstack/nova/+/983333 | |
| 23:51:49 | opendevreview | Merged openstack/nova master: Add nova-vtpm job https://review.opendev.org/c/openstack/nova/+/978841 | |
| #openstack-nova - 2026-04-04 | |||
| 03:14:28 | opendevreview | melanie witt proposed openstack/nova master: TPM: support live migration of `deployment` secret security https://review.opendev.org/c/openstack/nova/+/925771 | |
| 03:14:28 | opendevreview | melanie witt proposed openstack/nova master: TPM: test live migration between hosts with different security https://review.opendev.org/c/openstack/nova/+/952629 | |
| 03:14:30 | opendevreview | melanie witt proposed openstack/nova master: TPM: add late check for supported TPM secret security https://review.opendev.org/c/openstack/nova/+/956975 | |
| 03:14:30 | opendevreview | melanie witt proposed openstack/nova master: TPM: enable conversion of secret security modes via resize https://review.opendev.org/c/openstack/nova/+/962052 | |
| 03:17:42 | opendevreview | melanie witt proposed openstack/nova master: DNM vtpm tempest https://review.opendev.org/c/openstack/nova/+/957477 | |
| 03:26:10 | opendevreview | melanie witt proposed openstack/nova master: DNM vtpm tempest https://review.opendev.org/c/openstack/nova/+/957477 | |
| 03:36:39 | opendevreview | melanie witt proposed openstack/nova master: DNM vtpm tempest https://review.opendev.org/c/openstack/nova/+/957477 | |
| 07:25:30 | opendevreview | melanie witt proposed openstack/nova master: TPM: fixup for bump service version documentation https://review.opendev.org/c/openstack/nova/+/978836 | |
| 07:25:31 | opendevreview | melanie witt proposed openstack/nova master: TPM: support live migration of `user` secret security https://review.opendev.org/c/openstack/nova/+/983333 | |
| 07:25:31 | opendevreview | melanie witt proposed openstack/nova master: TPM: support live migration of `deployment` secret security https://review.opendev.org/c/openstack/nova/+/925771 | |
| 07:25:32 | opendevreview | melanie witt proposed openstack/nova master: TPM: test live migration between hosts with different security https://review.opendev.org/c/openstack/nova/+/952629 | |
| 07:25:32 | opendevreview | melanie witt proposed openstack/nova master: TPM: add late check for supported TPM secret security https://review.opendev.org/c/openstack/nova/+/956975 | |
| 07:25:33 | opendevreview | melanie witt proposed openstack/nova master: TPM: enable conversion of secret security modes via resize https://review.opendev.org/c/openstack/nova/+/962052 | |
| 07:36:12 | opendevreview | melanie witt proposed openstack/nova master: TPM: support live migration of `deployment` secret security https://review.opendev.org/c/openstack/nova/+/925771 | |
| 07:36:12 | opendevreview | melanie witt proposed openstack/nova master: TPM: test live migration between hosts with different security https://review.opendev.org/c/openstack/nova/+/952629 | |
| 07:36:13 | opendevreview | melanie witt proposed openstack/nova master: TPM: add late check for supported TPM secret security https://review.opendev.org/c/openstack/nova/+/956975 | |
| 07:36:13 | opendevreview | melanie witt proposed openstack/nova master: TPM: enable conversion of secret security modes via resize https://review.opendev.org/c/openstack/nova/+/962052 | |
| 09:11:51 | opendevreview | melanie witt proposed openstack/nova master: DNM vtpm tempest https://review.opendev.org/c/openstack/nova/+/957477 | |
| 23:22:43 | opendevreview | melanie witt proposed openstack/nova master: TPM: support live migration of `user` secret security https://review.opendev.org/c/openstack/nova/+/983333 | |
| 23:24:26 | opendevreview | melanie witt proposed openstack/nova master: TPM: support live migration of `deployment` secret security https://review.opendev.org/c/openstack/nova/+/925771 | |
| 23:24:27 | opendevreview | melanie witt proposed openstack/nova master: TPM: test live migration between hosts with different security https://review.opendev.org/c/openstack/nova/+/952629 | |
| 23:24:27 | opendevreview | melanie witt proposed openstack/nova master: TPM: add late check for supported TPM secret security https://review.opendev.org/c/openstack/nova/+/956975 | |
| 23:24:28 | opendevreview | melanie witt proposed openstack/nova master: TPM: enable conversion of secret security modes via resize https://review.opendev.org/c/openstack/nova/+/962052 | |
| #openstack-nova - 2026-04-05 | |||
| 13:07:51 | opendevreview | Takashi Kajinami proposed openstack/nova-specs master: libvirt: AMD SEV-SNP support https://review.opendev.org/c/openstack/nova-specs/+/983376 | |
| 13:41:52 | opendevreview | Takashi Kajinami proposed openstack/nova-specs master: libvirt: AMD SEV-SNP support https://review.opendev.org/c/openstack/nova-specs/+/983376 | |
| 14:07:30 | opendevreview | Takashi Kajinami proposed openstack/nova-specs master: libvirt: AMD SEV-SNP support https://review.opendev.org/c/openstack/nova-specs/+/983376 | |
| 14:34:07 | opendevreview | Takashi Kajinami proposed openstack/os-traits master: Add a new trait for AMD SEV-SNP https://review.opendev.org/c/openstack/os-traits/+/983378 | |
| 15:41:34 | opendevreview | Takashi Kajinami proposed openstack/os-traits master: Add a new trait for AMD SEV-SNP https://review.opendev.org/c/openstack/os-traits/+/983378 | |
| #openstack-nova - 2026-04-06 | |||
| 17:43:36 | melwitt | dansmith: I'm going over your comments but something unrelated to the review that I keep forgetting is that barbican secrets when created default to having project_access=true which means the permission is for the project, not only the user | |
| 17:44:44 | dansmith | really? I thought it was the opposite | |
| 17:44:50 | melwitt | so I'm thinking I wonder if the doc for vTPM might be a bit misleading since it says "owned by the user" because it's really owned by the user and its project | |
| 17:45:55 | melwitt | I had thought so too but apparently no. not sure if it's always been like that or if something could have changed | |
| 17:46:04 | dansmith | either way, it doesn't matter from the perspective of the admin, which is the one doing the live migrating right? I guess I'm not sure which of my comments is yielding this clarification though... | |
| 17:47:22 | melwitt | that's right | |
| 17:47:52 | melwitt | it's not, it's just something i thought of while I was adding 'user' support and wanted to mention it to you in case it made you think anything different | |
| 17:48:26 | dansmith | ah okay | |
| 17:49:12 | dansmith | well, I thought ade told us the opposite a long while back, but fair enough.. not sure that "owned by the user" would mean anything other than "...and the project" to most readers since that's the default for most resources, | |
| 17:49:19 | dansmith | unless we say "and NOT the project" somewhere | |
| 17:49:32 | dansmith | but not opposed to clarifying in the docs (of course) either way | |
| 17:49:45 | dansmith | where is that default set or overridden? | |
| 17:50:06 | dansmith | like, barbican-side or us as the client? | |
| 19:00:57 | melwitt | dansmith: I saw the doc here while I was writing a tempest test for 'user' that adds the admin via ACL https://docs.openstack.org/api-guide/key-manager/acls.html#default-acl but I will go see if I can find where that is actually defaulted | |
| 19:10:24 | melwitt | looks like it is defaulted to true in the ACL model https://opendev.org/openstack/barbican/src/branch/master/barbican/model/models.py#L1243 and the ACL object https://opendev.org/openstack/barbican/src/branch/master/barbican/objects/secret_acl.py#L32 so I guess the question is, does every created secret get an ACL record automatically or does that only happen if the ACL API is called | |
| 19:14:42 | melwitt | I also don't see any way to create a secret and specify private from the get go https://docs.openstack.org/barbican/latest/api/reference/secrets.html so I guess in order to avoid a window where the ACL is open to the project, you would have to 1) create a metadata-only secret 2) create an ACL with project_access=false 3) PUT the payload to the metadata-only secret | |
| 19:14:50 | melwitt | maybe I'm not understanding this right | |
| 19:17:48 | dansmith | hmm, well, (a) if it's server-side we should probably avoid any statements in our docs about "how it is" and (b) maybe we should ask just to make sure | |
| 19:18:01 | dansmith | I was thinking there was also a "nobody (not even the owner) can see it until it has an ACL of some kind" | |
| 19:18:16 | dansmith | like maybe the owner can always ACL it, but can't read it until they give themselves that permission? | |
| 19:18:39 | dansmith | kinda like unix ownership.. I can remove my own read access, but I can always give it back to myself if I own it | |
| 19:18:46 | melwitt | yeah I dunno :/ | |
| 19:20:19 | melwitt | yeah I agree, "how it is" could change. also I guess we could do whatever explicitly but that's not been the behavior up to now, so I would hesitate to change it if it's operating in a way that vtpm users are fine with | |
| 19:20:47 | melwitt | and yeah, it would be nice to ask if there is someone who could explain all the details | |
| #openstack-nova - 2026-04-07 | |||
| 03:33:34 | opendevreview | melanie witt proposed openstack/nova master: TPM: support live migration of `user` secret security https://review.opendev.org/c/openstack/nova/+/983333 | |
| 03:33:34 | opendevreview | melanie witt proposed openstack/nova master: TPM: fixup for bump service version documentation https://review.opendev.org/c/openstack/nova/+/978836 | |
| 03:33:35 | opendevreview | melanie witt proposed openstack/nova master: TPM: support live migration of `deployment` secret security https://review.opendev.org/c/openstack/nova/+/925771 | |
| 03:33:35 | opendevreview | melanie witt proposed openstack/nova master: TPM: test live migration between hosts with different security https://review.opendev.org/c/openstack/nova/+/952629 | |
| 03:33:36 | opendevreview | melanie witt proposed openstack/nova master: TPM: enable conversion of secret security modes via resize https://review.opendev.org/c/openstack/nova/+/962052 | |
| 03:33:36 | opendevreview | melanie witt proposed openstack/nova master: TPM: add late check for supported TPM secret security https://review.opendev.org/c/openstack/nova/+/956975 | |
| 03:33:37 | opendevreview | melanie witt proposed openstack/nova master: TPM: handle key manager Forbidden errors consistently https://review.opendev.org/c/openstack/nova/+/983504 | |
| 03:33:37 | opendevreview | melanie witt proposed openstack/nova master: TPM: clean up orphaned libvirt secret on guest creation failure https://review.opendev.org/c/openstack/nova/+/983505 | |
| 10:52:03 | opendevreview | Robbert Nijgh proposed openstack/nova master: Remove proxy wrapping in libvirt device listing, slowing down update_available_resource https://review.opendev.org/c/openstack/nova/+/983529 | |
| 13:27:51 | MaxLamprecht[m] | sean-k-mooney: Can you maybe have another look at this https://review.opendev.org/c/openstack/nova/+/934984. We merged already the reproducer a while ago | |
| 13:29:16 | MaxLamprecht[m] | Would be great to also get https://review.opendev.org/c/openstack/nova/+/958556 reviewed/merged. | |
| 13:32:06 | sean-k-mooney | MaxLamprecht[m]: sure. ill see if i can do it before my next meeting at the top of the hour but i also need to prepare some contet for that | |
| 13:32:58 | sean-k-mooney | it looks like dan is now happy with it and there has only been 1 revision since i last looked so i suspect this will be good to proceed | |
| 13:37:46 | dansmith | I wasn't ever unhappy, I just thought we should wait until after the release | |
| 13:42:04 | sean-k-mooney | ack, i just fisnihed reviewin git i think its ok to proceed with although i wont have tiem to look at the other 2 related repoduces/fixes today | |
| 13:45:46 | sean-k-mooney | im not agaisnt fixing the correct handeling fo build, rescheduler and migate seperatly so that they are indepently backportable bu i am wondering if we need a better long term fix for this in general. i have not spent any time thinkign what that could look like however. im just concerned that unshelve or resize will be next | |
| 13:53:13 | MaxLamprecht[m] | thx, as far what I can tell, these fixes are pretty good for the nova side. We have all of them running since the beginning of this year and our cinder/nova out of sync problems reduced a lot. At least I can't even report a single new case that is nova related currently. I have 2 more race conditions on cinder side that I will submit there. | |
| 14:01:16 | sean-k-mooney | MaxLamprecht[m]: that good context. so you do not currently expect to need to adress simialr failures in other nova codepaths out side of the 2 other you have already sumbited bugs/fixes for? | |
| 14:01:32 | sean-k-mooney | at least based on your current workloads/usage patterens | |
| 14:11:53 | dansmith | sean-k-mooney: oh I was talking about this: | |
| 14:11:54 | dansmith | https://review.opendev.org/c/openstack/nova/+/958556 | |
| 14:12:04 | dansmith | this ^ should be a slam dunk early in the cycle I think | |
| 14:13:46 | sean-k-mooney | dansmith: oh ok and ya i think we can proceed with that ill loop back to it whne im finished with the cybrog team meeting | |
| 14:34:47 | MaxLamprecht[m] | sean-k-mooney: Exactly! | |
| 15:45:19 | melwitt | someone has reported a bug related to the tpool.Proxy wrapping of virNodeDevice of PCI devices during update_available_resource() https://bugs.launchpad.net/nova/+bug/2147424 saying that it causes update_available_resource() to increase time taken to complete over time. does anyone have any idea why this would be? if so, comments on the bug would be appreciated | |
| 15:48:41 | sean-k-mooney | did we fix that alreday | |
| 15:48:55 | sean-k-mooney | melwitt: that feels like something we did before | |
| 15:50:54 | melwitt | sean-k-mooney: they are saying that fix caused a different problem, that now update_available_resource() run time progressively increases over time. whereas the problem before the fix was that update_available_resource() could block other nova-compute eventlet threads. they are proposing a revert but I don't see how it could be that simple? | |
| 15:52:30 | melwitt | (i.e. wouldn't that return things to the blocked threads problem) | |
| 15:53:23 | gibi | clearly reverting until we know a bit more about the root cause of the increasing runtime feel premature to me | |
| 15:53:29 | melwitt | I don't really get how tpool.Proxy wrapping could result in a run time increase for the periodic task | |