| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2025-11-20 | |||
| 10:53:03 | sean-k-mooney | either of which we wexpct to be merged | |
| 10:56:40 | andreykurilin | Got it. Thank you for helpful notes | |
| 10:57:44 | sean-k-mooney | i dont know if it would make sense to eventully build a "image fixer" type tool that operator could use but kind of feels out os scope of oslo utils | |
| 10:58:07 | sean-k-mooney | maybe but i dont know of anyoen working on that. | |
| 10:58:45 | sean-k-mooney | since legacy or uefi boot is select as a image property on the image that is uploaded you will have seperate copies fo the iamge for each mode in glance | |
| 10:59:48 | sean-k-mooney | so you coudl do what was provided as the flatcar workaround, i dont think glance woul dwant to supprot that itself but it does have interoperatble import plugings for format conversion amoung other things | |
| 11:00:22 | sean-k-mooney | so that may also be an opetion eventully. however that somethign you would have to talk to the oslo or glance folks about | |
| 11:08:23 | nelljerram | elodilles: Thanks for pushing my cherry picks along. You mentioned on https://review.opendev.org/c/openstack/nova/+/967569 that the grenade job needs investigation - can you suggest some more detail for how I can do that? (If there is something more specific than the general guidance at https://docs.openstack.org/project-team-guide/testing.html#how-to-handle-test-failures) | |
| 11:10:13 | andreykurilin | sean-j-mooney: yeah, “image fixer” sounds great, but from my noob point of view - too high risk to damage “nobody-known-who-and-how-built-this” user image. May not worth the effort. And definitely out of scope of oslo.utils . Thank you for all your input! | |
| 11:27:40 | opendevreview | John Garbutt proposed openstack/nova master: WIP: Ironic: on delete wait for cleaning to finish https://review.opendev.org/c/openstack/nova/+/967824 | |
| 11:27:40 | opendevreview | John Garbutt proposed openstack/nova master: WIP: Ironic: add logs during provision failures https://review.opendev.org/c/openstack/nova/+/967823 | |
| 11:58:07 | DominikDanelski[m] | Is there any reason why we would want allocations left by a VM that was over quota and never entered ACTIVE to be left in Placement? | |
| 12:02:17 | DominikDanelski[m] | I observed it with unified limits and I'm not sure if that's an error or an intended course of things. Doesn't seem to make sense to me, but maybe there's some underlying reason I'm not aware of. | |
| 12:54:07 | elodilles | nelljerram: thanks for looking into the issue! I've commented on the patch, let's see if my grenade patch fixes the issue when it merges | |
| 13:07:33 | nelljerram | elodilles: many thanks, fingers crossed | |
| 14:08:42 | priteau | Hello. We have a customer who has raised an interesting issue: they have some tooling using server groups and affinity/anti-affinity rules and were expecting it to work out of the box in a Nova+Ironic context, with affinity policy preventing scheduling and anti-affinity working. However, I think what is happening is that the affinity/anti-affinity filter uses the nova-compute | |
| 14:08:44 | priteau | host as a comparison, correct? | |
| 14:15:26 | opendevreview | ribaudr proposed openstack/nova master: Use *_OR_ADMIN policy defaults for server shares https://review.opendev.org/c/openstack/nova/+/967709 | |
| 15:08:46 | opendevreview | Rajesh Tailor proposed openstack/nova master: Fix memory_details units in diagnostics API to match documentation https://review.opendev.org/c/openstack/nova/+/967505 | |
| 15:26:30 | opendevreview | Balazs Gibizer proposed openstack/nova master: Do not fork compute workers in native threading mode https://review.opendev.org/c/openstack/nova/+/965466 | |
| 15:26:31 | opendevreview | Balazs Gibizer proposed openstack/nova master: Libvirt event handling without eventlet https://review.opendev.org/c/openstack/nova/+/965949 | |
| 15:26:31 | opendevreview | Balazs Gibizer proposed openstack/nova master: Compute manager to use thread pools selectively https://review.opendev.org/c/openstack/nova/+/966016 | |
| 15:26:32 | opendevreview | Balazs Gibizer proposed openstack/nova master: WIP:Move eventlet specific libvirt event handling https://review.opendev.org/c/openstack/nova/+/967178 | |
| 15:26:32 | opendevreview | Balazs Gibizer proposed openstack/nova master: Run nova-compute in native threading mode https://review.opendev.org/c/openstack/nova/+/965467 | |
| 15:44:08 | opendevreview | Balazs Gibizer proposed openstack/nova master: DNM:Test with oslo.vmware eventlet removal patches https://review.opendev.org/c/openstack/nova/+/967487 | |
| 18:06:20 | dansmith | melwitt: I just had a thought as I start looking at deployment mode | |
| 18:06:43 | dansmith | melwitt: if I create an instance, snapshot it, and then delete it.. I'm going to lose my TPM key | |
| 18:07:05 | dansmith | since we don't snapshot the TPM with the instance, that's fine now | |
| 18:07:35 | dansmith | but I guess I'm not sure what the long-term intent here is.. maybe we won't ever want to save the TPM with a snapshot for the cloud-fork case, but for the "I snapshot for backup reasons" case it's more relevant... | |
| 18:09:10 | sean-k-mooney | well that woudl be requried if we ever supprot shelve | |
| 18:09:17 | sean-k-mooney | but yes that was one of the opens | |
| 18:09:31 | sean-k-mooney | do we ever supprot snapthosting the tpm and wehre to put the data | |
| 18:11:41 | sean-k-mooney | we brifly dicussed if you woudl also need a api chagne to allwo requesting it to be snapshot and or restored in rebuild because you mihgt want to rebuidl the root disk without regenerating the tpm | |
| 18:12:09 | dansmith | shelve doesn't suffer from us deleting the tpm key in deployment mode, which is what I'm focusing on here | |
| 18:13:33 | sean-k-mooney | well at the moment sicne we dont store the tpm data the fact we delet the tpm key when the vm is deleted is consitent | |
| 18:14:22 | sean-k-mooney | its a problem for the boot, setupm snapshot and boot many form snapshot workflow | |
| 18:14:53 | sean-k-mooney | but that not really in scope of the live mitration feature is it | |
| 18:15:52 | sean-k-mooney | dansmith: are you suggeting in the curernt proposed code rebuilting woudl delete the tpm secrete? | |
| 18:16:16 | sean-k-mooney | i.e. just dong boot, snapshot, rebuild? | |
| 18:16:24 | sean-k-mooney | without the delete step? | |
| 18:18:16 | dansmith | I'm just saying that we're deleting the secret on instance delete in deployment mode but not the others (of course) and that may be surprising for cases like boot, snapshot, delete, boot-from-snapshot, for whatever reason you might do that (cross-nova rebuilding, boot from backup, etc) | |
| 18:18:40 | dansmith | obviously we're not storing the TPM so that's to be expected now, I'm just noting the difference | |
| 18:19:09 | sean-k-mooney | ack that because the secret is owned by nova | |
| 18:19:22 | sean-k-mooney | is the tpm secrete ever deleted in the user case | |
| 18:19:36 | sean-k-mooney | i woudl expect it to be deleted with the vm in the case also | |
| 18:19:53 | dansmith | it can't be | |
| 18:20:02 | sean-k-mooney | why we have the users token | |
| 18:20:10 | sean-k-mooney | for the delete unless an admin did it | |
| 18:20:31 | dansmith | not always.. admin delete, local delete, init_host() finish delete, etc | |
| 18:20:51 | sean-k-mooney | so instead of clenaing it up in the case we can we leak it alwasy? | |
| 18:21:06 | sean-k-mooney | im not saying that a bug but its surprisng to me | |
| 18:21:26 | dansmith | actually, you're right, we are deleting it in those cases, we'll just fail to actually do it in the cases I'm noting | |
| 18:21:38 | sean-k-mooney | so we proably need to document the key deletion semantics clearly for all 3 cases in any event | |
| 18:21:40 | dansmith | melwitt: ^ | |
| 18:22:43 | sean-k-mooney | so i know admin cant read the secret | |
| 18:22:58 | sean-k-mooney | but i tought he admin user can list and delete them in barbcan | |
| 18:23:04 | sean-k-mooney | did i imagine that | |
| 18:24:18 | sean-k-mooney | https://github.com/openstack/barbican/blob/master/barbican/common/policies/secrets.py#L41-L49 | |
| 18:24:23 | dansmith | maybe? but in local_delete and init_host cleanup we won't even have (or use) that | |
| 18:24:41 | sean-k-mooney | well we do via nova credital | |
| 18:24:55 | sean-k-mooney | i.e. the nova user shoudl have service and admin | |
| 18:24:55 | dansmith | we won't use it, AFAIK | |
| 18:25:00 | sean-k-mooney | oh ok | |
| 18:25:07 | dansmith | ideally it won't forever though | |
| 18:25:35 | sean-k-mooney | maybe we coudl to make it consitent in all cases. we wont have admin you mean? just service right? | |
| 18:25:51 | dansmith | correct | |
| 18:25:54 | sean-k-mooney | allowing the service role to delete a secret might make sense | |
| 18:26:07 | sean-k-mooney | but that is not in there policy today | |
| 18:26:31 | dansmith | eh, idk, if we just make service do everything admins can do that also kinda defeats the point | |
| 18:27:05 | sean-k-mooney | ya i guess im not sure which side fo the ling this falls under | |
| 18:28:01 | sean-k-mooney | in any case it sounds like we cant guarentee cleanup in most cases | |
| 18:28:28 | sean-k-mooney | althogh it will work in a subset so users or admins will need to discuvoer and remove the secrets perodicly | |
| 18:28:28 | dansmith | melwitt: so when you read the backscroll, ignore my line about losing the TPM key only under deployment mode, but we might want to consider/test/fix late deletes and make them use your nova credential to do the delete in cases where we don't have local creds anymore | |
| 19:31:39 | melwitt | dansmith: what do you mean by local creds? libvirt secrets store on the compute in the case of 'host' mode? the proposed code tries to lookup the libvirt secret first and if it doesn't find it, it falls back to pulling it from barbican | |
| 19:31:53 | melwitt | *stored | |
| 19:32:08 | dansmith | melwitt: I meant the nova service user | |
| 19:32:35 | melwitt | ok, the word "local" is confusing me | |
| 19:32:56 | dansmith | melwitt: like, compute was down, user did a delete, when we come backup and finish the local delete we don't have any creds to talk to barbican other than the service user | |
| 19:33:21 | melwitt | ok I see | |
| 19:33:55 | dansmith | probably also for soft/delayed delete | |
| 19:34:20 | melwitt | I'll check through that and add test coverages for it. I remember covering all that when I worked on ephemeral encryption but I'm not sure if I remembered it for this | |
| 19:34:34 | dansmith | ack | |
| 19:35:37 | melwitt | I think the deferred delete is taken care of already but yeah would be best to test specifically for that as well. I'll work on covering all of the late delete possibilities | |
| 19:36:13 | dansmith | okay, I didn't see where that would be, but we have loooots of delete indirection going on, so I'm sure I missed it :) | |
| 19:54:57 | melwitt | dansmith: for the deferred delete stuff it's compartmentalized into the "complete_deletion" methods, like deleting secrets and all that happens in "complete deletion" which does not run until the reclaim periodic task runs which checks for deferred delete expiry and "completes deletion" if the time has expired | |
| 19:57:14 | melwitt | (deferred delete meaning the soft delete API) | |
| 20:21:53 | dansmith | melwitt: right, but if we're in host or user mode we don't have a context with user creds to do the delete in barbican right? | |
| 20:23:39 | dansmith | like if we arrive at that code synchronously with a user- or admin-initiated delete, then we will | |
| 20:24:09 | dansmith | but if we're in that code because we're completing a local delete we won't unless I'm missing something | |
| 20:41:27 | melwitt | dansmith: ok yeah I see what you're saying now | |
| 20:43:47 | melwitt | the problem must be already present with plain vTPM as it is today.. since it's all user owned secrets | |
| 21:23:37 | Zhan[m] | hey team I'm wondering when is the next spec freeze? and it's for 2026.1 or 2026.2? I saw in the agenda that it writes "Soft spec freeze November 20th !". | |
| 21:29:05 | melwitt | Zhan[m]: the soft spec freeze today is for 2026.1 and IIUC it means the last day to propose a new spec to openstack/nova-specs: "After 20 November 2025 (23:59 UTC), no new specs will be accepted." https://releases.openstack.org/gazpacho/schedule.html#g-nova-spec-soft-freeze | |
| 21:30:46 | melwitt | and then Dec 4 is the hard spec freeze meaning the deadline for spec approvals i.e. no more approvals after Dec 4 | |
| 21:31:31 | Zhan[m] | melwitt: Thanks for explaining and the link! I guess my spec needs to go to 2026.2 :P | |
| 21:36:14 | melwitt | realistically yes :) if you have it ready to go and can upload within the next 2 hours before 23:59 UTC then you can try | |
| 21:36:21 | dansmith | melwitt: right exactly, nothing new with this series, just thinking we can now fix it since we have your use-the-service-user stuff | |
| 21:37:22 | melwitt | yeah, gotcha | |
| 23:22:46 | opendevreview | Jay Faulkner proposed openstack/nova master: [ironic] Ensure unprovision happens for new states https://review.opendev.org/c/openstack/nova/+/967941 | |
| 23:24:25 | opendevreview | Jay Faulkner proposed openstack/nova master: [ironic] Ensure unprovision happens for new states https://review.opendev.org/c/openstack/nova/+/967941 | |