October 2024 - openstack-discuss - lists.openstack.org

[Horizon] Cancelling weekly meeting tomorrow
by Tatiana Ovchinnikova 22 Oct '24

22 Oct '24

Hello team, Since we have vPTG sessions, I'm cancelling our weekly meeting tomorrow. With kind regards, Tatiana

1 0

[dev][cinder] Bubbling up maintenance status on a volume from a third-party backend
by David Pineau 22 Oct '24

22 Oct '24

Hello Openstack and Cinder team, I'm currently working on the storage management layer of our company's Openstack platform. As we manage the storage ourselves, we may run background operations, which are akin to a maintenance, on individual volumes, or part of the infrastructure. As a bit of context, this infrastructure will be both exposed to external customers, as well as internal departments, and as such, we are looking for a refined user experience where an error is not a simple "an error occurred in service X", but something potentially actionable by whoever encounters it. At the moment in the Cinder documentation (and what I could find on the discuss archive), there seems to be no way for a Cinder Driver and its backing services to: - Tell Cinder that a specific Volume is undergoing a backend maintenance and should be considered unavailable - raise a relevant error to Cinder about ongoing Operations affecting a Volume within its backend, that cinder could properly react to As a first step, I wanted to check if you, the community, had ever considered this issue (or at least we consider it to be one). We'd be very happy if you had recipes or pieces of advice to share with us on how to handle this. If nothing is available or known, how could we help in bringing such an improvement to Cinder ? Kind regards, -- David Pineau (joa)

3 5

[Openstack-ansible]- Need to delete VM with its OS disk even if it has active snapshot available.
by Danish Khan 22 Oct '24

22 Oct '24

Dear All, When I delete a VM then the OS disk of the VM remains even when I have marked the Volume to get deleted on VM deletion. This is happening only when we have a snapshot of the OS disk or snapshot of the complete VM available. Can we configure it in a way then either that the VM should get deleted completely with OS disk even if we have the snapshot available or the VM deletion task should fail if the snapshot is available. Regards, Danish

1 0

[nova][libvirtd] internal error: unable to execute QEMU command 'query-named-block-nodes'
by Satish Patel 22 Oct '24

22 Oct '24

Folks, I have a ceph cluster and recently I configured rbd-mirror to replicate all data to remove ceph cluster for disaster recovery. Yesterday for POC we did a hard cutover on ceph and point openstack to the new cluster. All other vms came back up fine but 2 vms stuck in this error state in libvirt logs 2024-01-31 22:44:37.591+0000: 474597: error : qemuMonitorJSONCheckErrorFull:399 : internal error: unable to execute QEMU command 'query-named-block-nodes': cannot read image start for probe: Permission denied If it's a wider issue than it should impact all the vms but why only two VM stuck and not starting and libvirt giving me this error in logs nova-compute logs also showing same error 2024-01-31 22:44:40.925 7 INFO nova.compute.manager [None req-b33485b5-8740-48ae-8b5b-a440de3f11a4 c48fcfb9347f413f92fcece065644b00 ca5c652478c7429e964257990800e9cb - - default default] [instance: 2de0f880-77c7-4d2c-9e01-898c57ad3693] Successfully reverted task state from powering-on on failure for instance. 2024-01-31 22:44:40.944 7 ERROR oslo_messaging.rpc.server [None req-b33485b5-8740-48ae-8b5b-a440de3f11a4 c48fcfb9347f413f92fcece065644b00 ca5c652478c7429e964257990800e9cb - - default default] Exception during message handling: libvirt.libvirtError: internal error: unable to execute QEMU command 'query-named-block-nodes': cannot read image start for probe: Permission denied

3 8

[swift][ptg] Ops Feedback Session - 23 October at 14:00 UTC
by Tim Burke 22 Oct '24

22 Oct '24

As we've done in PTGs past, we're getting devs and ops together to talk about Swift: what's working, what isn't, and what would be most helpful to improve. We're meeting on meetpad (https://meetpad.opendev.org/p/swift-epoxy-ops-feedback) on Wednesday at 14:00UTC -- if you run a Swift cluster, we hope to see you there! Even if you can't make it, we'd appreciate it if you can offer some feedback on the etherpad (https://etherpad.opendev.org/p/swift-epoxy-ops-feedback) This has always been a highlight at every PTG for the swift developers. Have your say and help make the next Swift the best one yet! Tim

1 0

[all][rbac] Canceling policy popup team tomorrow meeting
by Ghanshyam Mann 22 Oct '24

22 Oct '24

Hello Everyone, Due to vPTG weeks, I am cancelling the policy pop-up tomorrow meeting. https://wiki.openstack.org/wiki/Consistent_and_Secure_Default_Policies_Popu… -gmann

1 0

[cinder] 2025.1 PTG reminder
by Jon Bernard 21 Oct '24

21 Oct '24

Hello all, We covered the schedule in last week's meeting but I wanted to post it here for reference. For Cinder, we are meeting Wednesday, Thursday, and Friday of this week from 14:00 UTC until 17:00 UTC. I have consolidated and updated our etherpad [1] to include both a tentative schedule that includes cross-project session commitments and the set of proposed topics. As we did in the previous PTG, we'll be using the same google meet link and the sessions will be recorded. Everything should be noted in the etherpad. If you notice something is missing please add it or reach out with any questions. See you all in a couple of days! [1] https://etherpad.opendev.org/p/epoxy-ptg-cinder -- Jon

1 0

[openstack-helm] 2025.1 PTG reminder
by Vladimir Kozhukalov 21 Oct '24

21 Oct '24

Hi dear helmers, This is a reminder that we have a PTG session scheduled at 15:00-18:00 UTC on Wednesday 2024-10-23 [1]. This time we have quite a lot to discuss (and this is good) so I booked a 3 hours session (instead of our usual 2 hours). If you have something to discuss please put topics to the Etherpad [2] [1] https://ptg.opendev.org/ptg.html [2] https://etherpad.opendev.org/p/oct2024-ptg-os-helm -- Best regards, Kozhukalov Vladimir

1 0

Spot Instances
by Mia 21 Oct '24

21 Oct '24

Hello everyone, I am working on a project in the OpenStack environment. More precisely, I am looking into the implementation of spot instances as a cost optimization strategy and better resource utilization. If any community members could share their experiences and insights related to the following areas, it would be greatly appreciated. Implementation Strategies: How did you go about implementing spot instances in your cluster? Challenges Faced: Mention some of the challenges or limitations. Best Practices: Do you have any recommendations or best practices that you would like to suggest for seamless deployment? Thank you very much for your time and support.

8 11

[all][designate][manila] Grenade job failures caused by GLOBAL_VENV=True
by Takashi Kajinami 21 Oct '24

21 Oct '24

Just in case you are not aware of the situation. The change to enable GLOBAL_VENV in grenade job was recently merged[1] in core grenade. As we saw when the same was introduced in devstack some time ago, some project got their (grenade) jobs broken and need a few adjustments. [1] https://review.opendev.org/c/openstack/grenade/+/930507 So far I'm aware that the change affected manila and designate, which I'm fixing by the changes below. Please be careful in case you see grenade job failing in your project. designate: - https://review.opendev.org/c/openstack/designate/+/932697 Disable GLOBAL_VENV in grenade This is temporal workaround and needs to be reverted once the actual fix below is merged in master and backported to stable 2024.1/2 - https://review.opendev.org/c/openstack/designate/+/932697 devstack: Fix manage.py execution with GLOBAL_VENV This actually fixes the current issue caused by GLOBAL_VENV=True. As noted above, we have to backport this to stable branches manila: - https://review.opendev.org/c/openstack/manila/+/932671 Disable GLOBAL_VENV in grenade This is temporal workaround and needs to be reverted once the actual fix below is merged in master and backported to stable 2024.1/2 - https://review.opendev.org/c/openstack/manila/+/932665 devstack: Fix missing manila command This actually fixes the current issue caused by GLOBAL_VENV=True. As noted above, we have to backport this to stable branches Thank you, Takashi -- Takashi Kajinami irc: tkajinam github: https://github.com/kajinamit launchpad: https://launchpad.net/~kajinamit

4 4