| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2025-11-20 | |||
| 07:27:34 | opendevreview | huanhongda proposed openstack/nova master: live migration: Delete allocation if post_live_migration fails https://review.opendev.org/c/openstack/nova/+/967652 | |
| 09:48:42 | 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 | |
| 10:34:05 | opendevreview | Sahid Orentino Ferdjaoui proposed openstack/nova master: compute/manager: fix live migration issue due to orphaned attachments https://review.opendev.org/c/openstack/nova/+/967683 | |
| 10:36:54 | andreykurilin | Hi folks! I have a question regarding https://bugs.launchpad.net/nova/+bug/2091114 - how the operators are supposed to evacuate the hypervisor in case of emergency? Is there any way to bypass new check? | |
| 10:38:25 | sean-k-mooney | andreykurilin: in an emargency you cna disabel the secuirty messure on the target hypervior | |
| 10:38:43 | sean-k-mooney | the flatcar image have been fixed upstream | |
| 10:39:25 | andreykurilin | It does not relate to flatcar images only, some other vendors violated specifications as well | |
| 10:39:34 | sean-k-mooney | yep | |
| 10:39:54 | sean-k-mooney | so as an operator you have the option of enfocing specomplaine and saftey | |
| 10:40:02 | sean-k-mooney | on allowing unsefe images | |
| 10:40:39 | sean-k-mooney | we have taking the stance that all non spec complient images are unsafe | |
| 10:41:53 | sean-k-mooney | you coudl use shculder filters to move workload tha tuse unsafe images to a designated host aggarte | |
| 10:42:01 | andreykurilin | I agree with that and we want to enable this check for all new images. But at the same time it would be nice to fix existing images in iterative way without making the cloud less secure (i.e., disable all the checks) | |
| 10:42:02 | sean-k-mooney | or other means to partion your cloud | |
| 10:42:35 | sean-k-mooney | the only way to fix the iamges woudl be to modify the date for the image in glance | |
| 10:43:03 | sean-k-mooney | for flatcar that just ment removing a flag on the partion but you woudl have to download the image and reupload it | |
| 10:43:20 | sean-k-mooney | if it was an operator provded image you can do that but not a user image | |
| 10:44:33 | sean-k-mooney | the oslo image inspector module supprot a way of invoekign it fomr the command line on an image so you can test it locally | |
| 10:45:29 | andreykurilin | oslo image cli note - nice to now, thank you | |
| 10:48:13 | andreykurilin | I understand that fixing images require reuploading and interactions with end-users which takes time. Moving all existing VMs into dedicated HVs with disabled all image checks - sounds expensive :) right now we are leaning towards to patching oslo lib to remove this check so we have enough time to work with end users | |
| 10:48:40 | sean-k-mooney | https://github.com/openstack/oslo.utils/commit/8e6cf9556413f4ef3b75c09b3a42896a4d1b9253 | |
| 10:49:43 | sean-k-mooney | andreykurilin: that not somethign that is upstreamable but is somethign you coudl do in your cloud | |
| 10:52:00 | andreykurilin | Thank you | |
| 10:52:02 | sean-k-mooney | andreykurilin: i do have a patch to do that semi safely however it was never inteded really to merge just to demonstate what it woudl look like https://review.opendev.org/c/openstack/oslo.utils/+/937215/2/oslo_utils/imageutils/format_inspector.py | |
| 10:52:51 | sean-k-mooney | there is another similer patch https://review.opendev.org/c/openstack/oslo.utils/+/964528 | |
| 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 | |