- openstack-discuss - lists.openstack.org

[i18n][infra] Future of translate.openstack.org
by Tony Breeds 20 Dec '23

20 Dec '23

Hello all, The infra team is in the process of replacing older bionic servers with jammy based ones. We're nearing the end of that process and one of the remaining servers is translate.openstack.org. This server is primarily running zanata, which if I understand correctly, is no longer in use by the i18n team. I understand that there is a new platform that requies some tooling, if a dedicated server is needed for that we can spin up a newer jammy based server. So can we just retire this translate.openstack.org? Yours Tony.

3 3

[all][tc][ptls] Eventlet: Python 3.12, and other concerning discoveries
by Jay Faulkner 20 Dec '23

20 Dec '23

Hi all, For those who aren't aware, eventlet (https://github.com/eventlet/eventlet) is a library that almost every OpenStack project depends on and uses heavily. It's the primary method in most OpenStack project for achieving any form of parallelism via greenthreading. A couple of weeks ago it was brought to my attention, in the #openstack-tc IRC channel, that the eventlet library was broken on python 3.12 due to changes to the SSL stdlib in python 3.12. I enlisted a G-Research Open Source Software (GR-OSS) developer from outside the OpenStack community, Itamar, to help dig into what would be required to get python 3.12 support for eventlet, and asked him to do an overall health check on the project. The results were extremely concerning, and are why I'm emailing the list today. First of all, the original concern -- python 3.12 support -- is being worked on right now; there is a PR up to migrate the SSL module here https://github.com/eventlet/eventlet/pull/817 and a PR up here: https://github.com/eventlet/eventlet/pull/820 to begin migrating from nose3, a deprecated testing framework used by eventlet which does not support python 3.12. It's worth noting that in the past (2020) https://github.com/eventlet/eventlet/issues/638 there was resistance to removing nose for testing due to at-the-time-desired python2.7 support. Even if they are able to be merged, these PRs only scratch the surface of the total effort needed to get eventlet working on python 3.12. Furthermore, activity on the eventlet project is extremely slim right now. There have been no commits to the primary branch in nearly eight months and it's been a single maintainer project for an extremely long time. There are also indications there may be external factors impacting the maintainers' availability. This lack of redundancy on a core library that we have no clear migration path off of is concerning as well. As a large community that uses eventlet; I hope we can improve it. Now we get to the cherry on top -- code quality and existing bugs. When Itamar began evaluating the overall state of the project, he found that approximately 80% of the unit tests were passing. Some of the failing unit tests were valid failures. In fact, one of the failure cases -- around locks not being properly greened on upgrade -- explains an Ironic database migrations unit test failure which we spent several weeks off-and-on debugging last cycle. Along these lines; although eventlet has CI configured; those tests have never passed: https://github.com/eventlet/eventlet/actions/workflows/test.yaml?query=is%3… . I don't have a specific proposal for a solution. I do know that right now, OpenStack services are built "all-in" on eventlet, with no obvious or easy migration path off. At least in the short term, keeping eventlet running well is critical to keeping OpenStack running well. I'm sending this email to raise an alarm about this situation, and to hope that community members can work together to solve the problem. Thanks for reading and your help, Jay Faulkner OpenStack TC Chair

8 15

[all] Python 3.12 issues and classes of bugs, helping me fixing them all...
by Thomas Goirand 20 Dec '23

20 Dec '23

Hi there! Since a few days, we have Python 3.12 as available interpreter version in Debian Unstable. All Debian packages were rebuilt by Lucas Neusbaumm, and about 60 Debian RC bugs were filled against the OpenStack related packages. You may have seen it in some of your projects, I was able to fix lots of bugs (so far: 28 bugs fixed since Wednesday morning, and counting...), and forwarded them to upstream OpenStack whenever possible: https://review.opendev.org/c/openstack/os-ken/+/903521 https://review.opendev.org/c/openstack/sahara-plugin-spark/+/903656 https://review.opendev.org/c/openstack/keystonemiddleware/+/903640 https://review.opendev.org/c/openstack/os-ken/+/903521 https://review.opendev.org/c/openstack/sahara-plugin-spark/+/903656 https://review.opendev.org/c/openstack/keystonemiddleware/+/903640 I'd appreciate reviews and merge for these, of course... Many reported issues were problems in a single package (like Eventlet, or taskflow not able to load asyncore), so some bugs were closed without any further action but an attempt of rebuilding the said package to check everything is as expected. However, for a lot of bugs, I do not know how to fix, which leads me to this message. Of course, mostly the hardest bugs are remaining now, as I fixes the most easy ones. Here's a few examples. In Barbican: https://bugs.debian.org/1058183 What is this "KeyError: slice(0, -1, None)" about? Many packages have the same issue (like networking-sfc, neutron-dynamic-routing, neutron-vpnaas, manila, rally and many others), so if I understand this class of bug, I'll be able to fix them all. Help would be very much appreciated on that one. In openstackclient: https://bugs.debian.org/1058097 The stackdump is: File "<frozen importlib._bootstrap>", line 1360, in _find_and_load File "<frozen importlib._bootstrap>", line 1331, in _find_and_load_unlocked File "<frozen importlib._bootstrap>", line 935, in _load_unlocked File "<frozen importlib._bootstrap>", line 1176, in exec_module File "<frozen codecs>", line 58, in <module> AttributeError: module 'sys' has no attribute 'byteorder' I don't really understand what's going on, but this smells like an issue in Python 3.12 itself. watcher: https://bugs.debian.org/1058377 looks like the interpreter segfauls when importing some modules in watcher.tests.api ?!? Mistral: https://bugs.debian.org/1058182 Manila: https://bugs.debian.org/1058182 AssertionError: Failed to wait for expected result: Execution f2a97f87-7b08-4171-819a-47e30a0a1840 must have reached state SUCCESS state but it is in RUNNING What's going on here? diskimage-builder: I was able to fix the "ModuleNotFoundError: No module named 'imp'" (that's trivial to fix, really...), but now I get: File "/usr/lib/python3/dist-packages/mock/mock.py", line 1245, in _importer thing = __import__(import_path) ^^^^^^^^^^^^^^^^^^^^^^^ ModuleNotFoundError: No module named 'growvols' looks like what I attempted to fix with rewriting a load_source (which is removed from Python 3.12) didn't work. python-pykmip: https://bugs.debian.org/1058411 That one feels tricky. wrap_socket is gone from the standard ssl module, though the example given in here: https://docs.python.org/3/library/ssl.html#ssl.SSLContext.wrap_socket is to use something like this: with context.wrap_socket(sock, server_hostname=hostname) as ssock: but that wont work with the way pykmip is written. So probably it needs some kind of rewrite? Looks like there's some commits upstream to address it, but no new release, unfortunately. I probably should attempt packaging the last Git commit. oslotest: https://bugs.debian.org/1058373 The broken test case attemps to disable the 'sys' module, but it looks like its failing to do so. Is there a change of behavior in the interpreter? wsgi-intercept: https://bugs.debian.org/1058378 TypeError: HTTPSConnection.__init__() got an unexpected keyword argument 'cert_file' No idea how to fix that one... :/ There's more which I probably didn't classify above. The full list of bugs is here: https://bugs.debian.org/cgi-bin/pkgreport.cgi?which=maint&data=team%2Bopens… Please ignore the first 5 though, which I don't really maintain and don't really care about (these aren't Py 3.12 issues). Many thanks to anyone that will help. Cheers, Thomas Goirand (zigo)

4 3

[Senlin][tc][all] Senlin project marked inactive by TC
by Jay Faulkner 20 Dec '23

20 Dec '23

OpenStack Community, The Technical Committee marked the Senlin project inactive[0] due to failing CI jobs and general lack of contribution. If you rely on Senlin, please take notice that without intervention, it will not be part of future OpenStack releases, including 2024.1 (Caracal). The only way for a project to leave inactive status is to become active again, and be removed from the inactive list, or to be retired from OpenStack. For more information, please see our documentation[1] on inactive projects. I encourage the OpenStack community to rally and support Senlin to bring it back into active status. If you are an operator and want more information on how to contribute and get this project going, please reply to this email and someone will be glad to help. Thank you, Jay Faulkner OpenStack TC Chair 0: https://review.opendev.org/c/openstack/governance/+/902626 1: https://governance.openstack.org/tc/reference/emerging-technology-and-inact…

1 0

[ec2-api][tc][all] ec2-api project marked inactive by TC
by Jay Faulkner 20 Dec '23

20 Dec '23

OpenStack Community, The Technical Committee marked the ec2-api project inactive[0] due to failing CI jobs and general lack of contribution. If you rely on ec2-api, please take notice that without intervention, it will not be part of future OpenStack releases, including 2024.1 (Caracal). The only way for a project to leave inactive status is to become active again, and be removed from the inactive list, or to be retired from OpenStack. For more information, please see our documentation[1] on inactive projects. I encourage the OpenStack community to rally and support ec2-api to bring it back into active status. If you are an operator and want more information on how to contribute and get this project going, please reply to this email and someone will be glad to help. Thank you, Jay Faulkner OpenStack TC Chair 0: https://review.opendev.org/c/openstack/governance/+/902625 1: https://governance.openstack.org/tc/reference/emerging-technology-and-inact…

1 0

beginning with [masakari]
by Shubham Kumar Yadav 20 Dec '23

20 Dec '23

Hi, i have recently started working on Masakari (kubernetes in openstack) so i wanted some help with it please i was trying to test the masakari-instance_monitor & masakari-host-monitor but having trouble with it. i have created a pacemaker remote cluster (with pacemaker & corosync on controller nodes and pacemaker remote on compute node. *pcs statusCluster name: lab-clusterCluster Summary: * Stack: corosync * Current DC: lab-11053-26006-ceph-2 (version 2.1.2-ada5c3b36e2) - partition with quorum * Last updated: Thu Dec 14 08:41:41 2023 * Last change: Thu Dec 14 08:41:22 2023 by root via cibadmin on lab-11053-26006-ceph-1 * 6 nodes configured * 3 resource instances configuredNode List: * Online: [ lab-11053-26006-ceph-1 lab-11053-26006-ceph-2 lab-11053-26006-ceph-3 ] * RemoteOnline: [ lab-11053-26006-comp-1.cluster.local lab-11053-26006-comp-2.cluster.local lab-11053-26006-comp-3.cluster.local ]Full List of Resources: * lab-11053-26006-comp-1.cluster.local (ocf:pacemaker:remote): Started lab-11053-26006-ceph-1 * lab-11053-26006-comp-2.cluster.local (ocf:pacemaker:remote): Started lab-11053-26006-ceph-2 * lab-11053-26006-comp-3.cluster.local (ocf:pacemaker:remote): Started lab-11053-26006-ceph-3Daemon Status: corosync: active/enabled pacemaker: active/enabled pcsd: active/enabled* i have also created segment and added hosts(computes) in it. when i tried to test the masakari host monitor by manually powering off the compute node, masakari should move the vms from powered off computes to some running compute but after the compute is powered off vms still remains on the powered off compute. Am i missing some conf? is there any need to add some conf in nova and keystone too? in masakari engine logs i see host_failure.evacuate_all_instances = True instance_failure.process_all_instances = False host_failure.add_reserved_host_to_aggregate = False host_failure.ha_enabled_instance_metadata_key = HA_Enabled log_opt_values host_failure.ignore_instances_in_error_state = False host_failure.service_disable_reason = Masakari detected host failed. do you have any suggestion please let me know! Thank You

2 1

[oslo] Nominating tobias-urdin for etcd3gw core
by Takashi Kajinami 20 Dec '23

20 Dec '23

Hi team, I raised this topic in #openstack-oslo today and already got a few acks, but I'm sending this email here for an official proposal as well as record. The etcd3gw library is now extensively used by tooz as the primary implementation for etcd3 backend. Because Tobias is already a core reviewer in the tooz library, I propose adding him to the etcd3gw core as well. Please let me know in case anyone has any thoughts on the proposal. I'll add him to the group next week if we hear no objections. Thank you Takashi Kajinami

2 2

[cinder] Canceling next week's meeting (27th December)
by Rajat Dhasmana 20 Dec '23

20 Dec '23

Hello Argonauts, Since most of the team members will be on year end break, we have decided to cancel next week's cinder meeting that was going to be held on 27th December, 2023. A merry christmas and a happy new year to the team. See you all next year! Thanks Rajat Dhasmana

1 0

Reg the issue
by Rohit Sansiya 20 Dec '23

20 Dec '23

Sir, I want help regarding openstack project creation. While creating the project by using openstack project create then stuck the process and got the error regarding fail to discover available identity versions when contacting the url(http://controller11:5000/v3) & gateway timeout 504 kindly help. Your message is ready to be sent with the following file or link attachments: Rohit Sansiya https://sites.google.com/view/rpgcloud/research-india Note: To protect against computer viruses, e-mail programs may prevent sending or receiving certain types of file attachments. Check your e-mail security settings to determine how attachments are handled.

1 0

Re: about magnum capi for production
by Oliver Weinmann 19 Dec '23

19 Dec '23

4 7