August 2024 - openstack-discuss - lists.openstack.org

[trove][zaqar][vitrage] What to do with projects not supporting SQLAlchemy 2.x ?
by Thomas Goirand 25 Sep '24

25 Sep '24

Hi, A number of project still don't have support for SQLAlchemy 2.x, which is currently in Debian testing/unstable, and which will be the version in Debian 13 (aka: Trixie). If these project don't get quickly support for SQLAlchemy 2.x, they are going to drop (well, in fact, they were already kicked out of Debian Testing). Are these project still maintained? IMO, no support for SQLAlchemy 2.x is a reason good enough to declare they aren't... Cheers, Thomas Goirand (zigo)

2 2

Opensearch Service Update
by Daniel Pawlik 17 Sep '24

17 Sep '24

Hello, We would like to notify you that the Opensearch service [1] would be updated to a newer version on 17 September 2024 at 12:00 PM UTC. This procedure might take a while, depending of the cluster size. During that time, the Opensearch service would not be available. If anyone has any doubts, please reply to the email. Dan [1] - https://opensearch.logs.openstack.org/_dashboards/app/home

1 1

Re: Migratekit: near-live migrations from VMware to OpenStack
by Oliver Weinmann 14 Sep '24

14 Sep '24

Hi Mohammed, We struggled using virt-v2v directly with OpenStack. Our approach was using ovftool to export the VM as OVA and then create a qcow2 image that we can import in OpenStack. So many manual steps involved. So I tested your tool aganst vsphere 7.x vcenter. But I just can't manage to get it working. It keeps complaining about the path of the source VM. I can use the following just fine with virt-v2v: virt-v2v -v -x --password-file pass.txt -ic vpx:// user123(a)vcenter.somedomain.local /GE%Office%20One/Projects/esx01.somedomain.local?no_verify=1 test-vm-01 Using the same in your tool: docker run -it --rm --privileged \ -v /dev:/dev \ -v /usr/lib64/vmware-vix-disklib/:/usr/lib64/vmware-vix-disklib:ro \ --env-file <(env | grep OS_) registry.atmosphere.dev/library/migratekit:latest migrate \ --vmware-endpoint vcenter.somedomain.local \ --vmware-username user123 \ --vmware-password XXXXXX \ --vmware-path /GE%Office%20One/Projects/esx01.somedomain.local/test-vm-01 Results in: Error: vm '/GE%Office%20One/Projects/ esx01.somedomain.local/test-vm-01 ' not found I tried many different variants of the path none has worked. Is there a way to lookup the path of a VM? I can also use: virsh -c 'vpx:// user123(a)vcenter.somedomain.local /GE%Office%20One/Projects/esx01.somedomain.local?no_verify=1 list --all which shows me all VMs running on that particular ESXi host. Best Regards, Oliver

2 9

[charms] Proposing Rodrigo Barbieri for OpenStack Charms stable core
by Edward Hope-Morley 10 Sep '24

10 Sep '24

Hi everyone, I'd like to propose Rodrigo Barbieri for the OpenStack Charms stable maintenance team. Rodrigo has been a contributor to the charms for many years and has an impressive history of contributions to across all the OpenStack charms. He always demonstrates an attention to detail and provides insightful feedback in reviews and as such I believe he would make a valuable addition to our charms-stable maintenance core team. Thank you for your contributions to the project Rodrigo! Regards, Ed

2 1

[swift] Ideas: Object Locking
by David Zanetti 10 Sep '24

10 Sep '24

Hello everyone! We've added an entry to the Swift ideas page about implementing Object Locks. The full description of what this would be and how we expect it to work is in the ideas page here: https://wiki.openstack.org/wiki/Swift/ideas/object-lock I have two questions of the community. The first is whether work on this would be accepted by the Swift project, as we wouldn't want to expend efforts on something we'd have to carry as our own patches to upstream. The second is if there is any interest from other people to collaborate on design/implementation of the locking feature. Happy to take replies off-list if people prefer, and thanks for reading this far! (Ob-reply: Yes, we know Ceph RGW does this already. We use Swift for Object for $REASONS, which we'd like to keep doing.) -- David Zanetti Chief Technology Officer [1]Aotearoa New Zealand's cloud provider e david.zanetti(a)catalystcloud.nz w catalystcloud.nz Follow us on LinkedIn [2] Level 9, 33 Federal Street, Auckland 1010 [1] https://catalystcloud.nz/ [2] Follow us on LinkedIn https://www.linkedin.com/company/catalyst-cloud-limited/

2 1

[all][tc][ptls] Eventlet: Python 3.13 - Attach your seatbelt
by Herve Beraud 06 Sep '24

06 Sep '24

Hi all, As Python 3.13 is close to become a reality, new concerning incompatibilities between this new CPython version and Eventlet also become a reality: - https://github.com/eventlet/eventlet/issues/964 Fedora Python maintainers proposed a patch, but for now the problem remains unsolved. Also, many people reported bugs related to incompatibility between python3.12/dnspython/eventlet/pip-system-cert. There is an example who summarize well the problem https://github.com/eventlet/eventlet/issues/957 Do you have some visibility concerning the adoption of Python 3.13 into Openstack? Turbulences ahead... -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/

4 5

[charms] Proposing Brian Haley and Nicolas Bock for OpenStack Charms core
by Edward Hope-Morley 05 Sep '24

05 Sep '24

Hi everyone, I would like to propose Brian Haley and Nicolas Bock for the OpenStack Charms core development team. Both Brian and Nicolas have been members of the stable charms core team since 2023 and been hugely helpful in that role, providing insightful feedback to reviews as well as contributions of their own. Nicolas has also been a contributor to the OpenStack charms for many years and Brian is well versed in the ways of upstream OpenStack maintenance through his role as Neutron PTL so I have full confidence that they will prove valuable additions to the charms-core team. Thank you both for your contributions to the project! Regards, Ed

3 2

[Kolla] [LetsEncrypt] Internal/External/Backend Certificates
by jjjamesg＠proton.me 05 Sep '24

05 Sep '24

Hi all, another one here that can't seem to get kolla running with letsencrypt certs, just curious as to what settings are required for kolla to pull internal/external/backend certs from letsencrypt? I've looked at the docs and have tried a few settings but keep getting errors, sure i had this working last week before i tore it down ready to deploy for production and now i just cant get it to complete the deployment because of certs, only thing i can think of is i need to run kolla-ansible -i multinode certificates but i thought that was just for self made certs? Also, what are best practices for backend tls certs, self signed or using the internal cert etc?? Is it possible to use letsencrypt at all for backend? Cheers all

3 6

[cinder] Offering local storage using the device mapper clone target
by Jan Horstmann 04 Sep '24

04 Sep '24

Hello cinder team and other interested parties, I have recently started thinking about ways to offer local storage as part of the OpenStack block storage service. Naturally any solution would require to transparently migrate volumes to and with the instances they are attached to, so that the user experience of being able to access their storage from anywhere would not be degraded. Fortunately, with the device mapper clone target ([1]), a mechanism is available in the linux kernel which allows to do exactly that: Create copies of devices (even network attached ones) while allowing to immediately use the target device. I have detailed the motivation and some implications of having local storage in the block storage service in a blog post [2], which I do not want to repeat here in order to not make this mail longer than it needs to be. The blog post also outlines a way to implement a cinder driver leveraging this mechanism, which is loosely based on the way cinder migrates volumes between backends, i.e.: When a volume is going to be attached, a new volume is created on the instance's host, which is backed by a device mapper clone target with the original volume as its source; Then the volume objects are switched and a local connector is returned, which may be used immediately. Since then I went ahead and created a proof of concept cinder driver ([3]), which roughly follows what is outlined in the post (some lessons were already learned during implementation). The driver is based on the in-tree lvm driver for basic volume management and can do basic things like create/delete, attach/detach and also handles live migration and rebuilding of instances. There is nothing currently regarding snapshots and volume migrations will definitly not work as expected yet, but it should be sufficient to get a feeling for the general idea. I am currently looking for feedback on the idea and the implementation and would like to know if this is of interest to others. I am happpy to answer any questions or present this in more detail. In case anyone wants to take the driver for a spin I am going to leave some instructions on how to set up the environment in [4]. Regards, Jan [1] https://docs.kernel.org/admin-guide/device-mapper/dm-clone.html [2] https://scs.community/2024/07/12/local-block-storage-via-dm-clone/ [3] https://github.com/janhorstmann/openstack-cinder/tree/59e1808a24d112d2e8d08… [4] - Set up an OpenStack environment - Create an lvm2 volume group and run a cinder volume service on every hypervisor - Configure a new backend on every volume service with the same `volume_backend_name` Configure it like you would an lvm backend, but with `volume_driver = cinder.volume.drivers.dmclone.DMCloneVolumeDriver`, e.g.: [local-volumes] volume_driver = cinder.volume.drivers.dmclone.DMCloneVolumeDriver volume_group = local volume_backend_name = local-volumes target_helper = tgtadm target_protocol = iscsi lvm_type = default I have tested with the values above, but any target driver should work -- Jan Horstmann Senior Cloud Engineer Mail: horstmann(a)osism.tech Web: https://osism.tech OSISM GmbH Talweg 8 / 75417 Mühlacker / Deutschland Geschäftsführer: Christian Berendt Unternehmenssitz: Mühlacker Amtsgericht Mannheim, HRB 750852

1 1

[largescale-sig] Next meeting: August 21, 9utc
by Thierry Carrez 04 Sep '24

04 Sep '24

Hi everyone, The Large Scale SIG will be meeting this Wednesday in #openstack-operators on OFTC IRC, at 9UTC. You can doublecheck how that UTC time translates locally at: https://www.timeanddate.com/worldclock/fixedtime.html?iso=20240821T09 Feel free to add topics to the agenda: https://etherpad.opendev.org/p/large-scale-sig-meeting Regards, -- Thierry Carrez

3 2