March 2024 - openstack-discuss - lists.openstack.org

[kolla-ansible][Antelope][Heat] Heat UpdateWaitConditionHandle Issues
by Devin Patterson 17 Apr '24

17 Apr '24

Hello, We are creating a workflow to use Heat auto-scaling groups with wait conditions. The ideal goal would be to have the wait condition clear and require another signal when the Heat stack is updated. Trying to use the resource OS::Heat::UpdateWaitConditionHandle instead of OS::Heat::WaitConditionHandle. This works during initial creation, but when I udpdate the stack with a new configuration, I get the following error. UpdateWaitConditionHandle.update() got an unexpected keyword argument 'new_template_id' Any ideas on how to use wait conditions during stack updates or to fix the above error. Thanks in advance. Devin

2 2

[all][tc] Modernize Python Stack
by Niklas Schwarz 11 Apr '24

11 Apr '24

Hello, I have just ran over the mailing listing post OpenStack 2024.2 testing runtime by Ganshyam Mann [1] on dropping support for python3.8 for the upcoming Openstack 2024.2 release. This post and some small contributions to some openstack components have lead me to write this post. What I would like to suggest to modernize the Python-Stack used for OpenStack. Such a modernization includes: - A current python version - A modern and up to date static code analysis - Introduce type annotations Let me explain what I mean: A current python version: The current supported Python versions are Python 3.8 to Python 3.11 [2]. As of writing, OpenStack Yoga was just moved to unmaintained. To install this release, e.g. on an Ubuntu Jammy operating system the packages are included in the Ubuntu-Packages. The default Python version on an Ubuntu 22.04 operating system is Python3.10. And looking at the support of the Python versions [3] Python 3.8 to 3.10 only receive security updates but the end is near for Python 3.8 to be out of support. The policy defined which Python version should be used for testing [4] will result that Python 3.8 is still used for the OpenStack 2024.1 release [5]. And this will also result in required support for Python3.8 in the upcoming releases of OpenStack. I my opinion the policy should be reworked and the OpenStack releases should be more aggressive on dropping support for older Python versions. Modern features of the language cannot be otherwise be used, therefor improvements in speed, security and general toolchain/ecosystem cannot be fully leveraged. By defining the lower bound of the Python Version we are limiting ourself to this version but we might also reduce the features we can use because of deprecations of the newer versions . A modern and up to date static code analysis: Currently flake8 and pylint are used both of which are modern analysis tools. But their configuration is in my opinion not up to date. Lets have a look at the configuration of the neutron-lib [6]. As seen a lot of rules are disabled by the configuration and are needed at the current moment at the state of the project. In addition some rules need to be adjusted such as the line length (80 characters is a very aggressive limit and on most modern displays a line length of 100 to 120 can fit without any problems, personal opinion). The adjustment of the static code analysis besides opinionated rules will lead me to my third point to modernize the Python stack used Introduce type annotations Python type annotations are well supported in the current Python versions and through the typing package additional types are added. The introduction of type annotations will improve the developer experience. This is also motivated by the Python foundation in pep-484 [7]. Because of the type annotation all modern IDEs can provide (more precise) type hints. The type hints can and in in my experience will reduce the introduction of bugs (accessing members or calling methods, no logical bugs) and will shorten the time to develop a new feature or fix a logical bug and do not run in runtime exceptions. The datatypes passed to a method are clear and we do not need to dig down a rabbithole to find out what is passed to a method. The name of a variable does not always tell the truth. As an example I want to look at a patch [8] for the neutron-vpnaas component. Christian Rohmann and I worked on this patch for the component together (this has also lead me to write this email) to improve the reconciling for VPNaaS. It took as along time to find out that a RouterInformation object is passed in to a method instead of a router but the variable was named router. We both agreed on that in the first place the naming of the variable was wrong but type annotations would have saved us a good amount of time. This does not mean that the naming is not important and that type annotations will save the world, the context which includes the name of variables is important and type annotations will add additional information to the context. And I have just touched the surface on what is possible with the introduction of type annotations, thinking of automatic document generation, test generation, even code generation,... As a reference to my point modernizing the static analysis this can then also include the introduction of mypy to check the types used. Of course such a change cannot be done in one big commit and needs time but I suggest to start adding type annotations and improve the overall code quality of the OpenStack services, starting with the oslo packages as they are used by mostly all OpenStack components. Of course such changes cannot be done for such a huge project in one day. It took a long time to remove support for Python 2. So I do not expect such changes to happen immediately. But it would be nice to have a discussion about it and maybe create a road map and adjust some policy on supported Python versions and create new policies how to write Python code and what additional tools should be used. I can also understand if not everything is possible but the last two points need to be addressed in my opinion. These changes will lead overall to better code quality but most important the introduction to the big code base will be easier for new developers and reviewers will also have a better time. Best regards Niklas [1] https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… [2] https://docs.openstack.org/tempest/latest/supported_version.html [3] https://devguide.python.org/versions/ [4] https://governance.openstack.org/tc/resolutions/20181024-python-update-proc… [5] https://governance.openstack.org/tc/reference/runtimes/2024.1.html [6] https://github.com/openstack/neutron-lib/blob/master/.pylintrc [7] https://peps.python.org/pep-0484/#rationale-and-goals [8] https://review.opendev.org/c/openstack/neutron-vpnaas/+/875745

15 27

[kolla-ansible][horizon]Create instance default parameters
by Franck VEDEL 11 Apr '24

11 Apr '24

Hi, With horizon, is it possible de have this default parameter when you create an instance: in source, create a new volume: « No ». And.. if it’s possible, how configure this with kolla-ansible ? Thank’s for your help. Franck

2 4

Nova filter based on VM metadata?
by Ken D'Ambrosio 08 Apr '24

08 Apr '24

Hey, all. I'm looking for a way to to filter to a particular aggregate based on arbitrary VM metadata. (E.g., maybe FACTER facts from Puppet that we pass to the VM as metadata.) Could someone point me toward documentation that might outline how to accomplish that? As I see it, there's really one thing I need to understand -- the rest I can probably glean from extant filters: how (or if) a filter could access a given VM's metadata from the API creation request (if that's even possible). Thanks! -Ken

3 3

[openstack-ansible] : Ussuri minor version update.
by keshav bareja 04 Apr '24

04 Apr '24

Hi Team I am planning to update my environment from the current ussuri minor version to the latest minor version available for the Ussuri. I found the procedure below. https://docs.openstack.org/openstack-ansible/ussuri/admin/upgrades/minor-up… I have some queries on this: 1. How to find the current minor release version of the Ussuri deployed on my environment? Is there any command or way that can help? 2. What is the latest minor version available for Ussuri? In the Ussuri release notes page I could see 2.10, can someone please confirm if 2.10 is the latest version? 3. Also I need to know the bug fixes between my current release to the latest minor ussuri release. 4. Can someone confirm what all pre-requisite I need to take care of before going with the update. 5. Anyone having experience with such minor updates , Please share precaution and recommendations, Ussuri Series Release Notes <https://docs.openstack.org/releasenotes/openstack-ansible/victoria.html> <https://docs.openstack.org/releasenotes/openstack-ansible/train.html> <https://bugs.launchpad.net/openstack-ansible/+filebug?field.title=Ussuri%20…> 21.2.10 <https://docs.openstack.org/releasenotes/openstack-ansible/ussuri.html#relno…>Security Issues <https://docs.openstack.org/releasenotes/openstack-ansible/ussuri.html#secur…> - This release eliminates following security issues: - OSSA-2021-005: https://security.openstack.org/ossa/OSSA-2021-005.html - OSSA-2021-006: https://security.openstack.org/ossa/OSSA-2021-006.html

2 5

[freezer] Project status update
by Dmitriy Rabotyagov 03 Apr '24

03 Apr '24

Hey there! In a previous email thread [1] an interest toward reviving the Freezer project was raised. As a result of the thread we've organized a first sync meeting with interested parties. It was a quite productive discussion and we came up with a couple of action points as a result of it. You can find more information in the etherpad [2] Among everything, one of the most important parts for now, is to step into the PTL role or move a project to a distributed leadership. At the moment the project is leadless, since there was no candidacy submitted for this election. We also agreed to schedule the next meeting on April 2 from 16-00 till 17-00 UTC and discuss progress and blockers which were found. I'm attaching an invitation to the meeting to the email. If it doesn't work, you can join on the mentioned time via the link [3] Hope to see you there and thanks for everyone who participated and stepped in for the project! [1] https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… [2] https://etherpad.opendev.org/p/freezer-status [3] https://meet.google.com/ckc-gevi-epe

1 2

[neutron] Proposing Ihar Hrachyshka as neutron core reviewer
by Brian Haley 02 Apr '24

02 Apr '24

Hello Neutrinos, I would like to nominate Ihar Hrachyshka for Neutron core reviewer (again). He's been leaving some very useful comments lately, moved-up in the reviewer stats over the past 90 days [0], and has a lot of OVN knowledge. Ihar was previously a core reviewer from 2015-2018 so most might already know him. I think he'd be a great re-addition to the team. Please vote with a +1/-1. [0] https://www.stackalytics.io/report/contribution?module=neutron-group&projec… Thanks, -Brian, Neutron PTL

8 8

[qa][ptg] Virtual Dalmatian vPTG Planning
by Martin Kopec 02 Apr '24

02 Apr '24

Hello everyone, here is [1] our etherpad for the Dalmatian/2024.2 virtual PTG. Please, add your topics there if there is anything you would like to discuss / propose ... You can also vote for time slots for our sessions so that they fit your schedule at [2]. We will most likely go with 1-hour slot per day, as they usually fit easier into everyone's schedule. The number of slots will depend on the number of topics proposed in [1]. [1] https://etherpad.opendev.org/p/apr2024-ptg-qa [2] https://framadate.org/pklG59pH47w6ZdJI Thanks, -- Martin Kopec Principal Software Quality Engineer Red Hat EMEA IM: kopecmartin

1 1

openstacksdk, ironicclient, os-fault: Please replace python3-appdirs dependency with platformdirs
by Thomas Goirand 01 Apr '24

01 Apr '24

Hi, 3 bugs have been opened in Debian to get appdirs replaced by platformdirs: https://bugs.debian.org/1067995 https://bugs.debian.org/1067999 https://bugs.debian.org/1068000 Here's the bug report content: > python3-appdirs is dead upstream[1] and its Debian maintainer has > indicated that it should not be included in trixie[2]. A recommended > replacement is python3-platformdirs[3], which is a fork of appdirs > with a very similar API. > > Please migrate from appdirs to platformdirs or some other replacement, > so that appdirs can be removed. > > Thanks, > smcv > > [1] https://github.com/ActiveState/appdirs/commit/8734277956c1df3b85385e6b308e9… > [2] https://bugs.debian.org/1060427 >[3] https://pypi.org/project/platformdirs/ Can we do that in upstream OpenStack, during the Dalmatian cycle? Cheers, Thomas Goirand (zigo)

3 3

[zun][neutron] cannot start container after stopping it
by James Leong 31 Mar '24

31 Mar '24

Hi all, I am having issues with the network being attached to a container. Here's my scenario: when I first created a container via the dashboard, I had a successful running container; then later, I attached a floating IP to it, and when I tried to stop and start the container, I got the following error message. Error response from daemon: Cannot restart container 780688e20528: failed to create endpoint zun-720f2207-86f8-4845-9434-b8f21aeafeb8 on network 8475928f-e65a-4e72-9b15-7de43a5b8853: NetworkDriver.CreateEndpoint: Virtual device creation failed. Any suggestions or recommendations are greatly appreciated. Best, James

2 1