August 2022 - openstack-discuss - lists.openstack.org

Fwd: DPDK+OVS with OpenStack
by Mark Wittling 23 Apr '25

23 Apr '25

Looking for someone who knows OpenStack with OpenVSwitch, and in addition to that, DPDK with OpenStack and OVS.I am using OpenStack Queens, with OpenVSwitch. The architecture I am using is documented here: https://docs.openstack.org/neutron/queens/admin/deploy-ovs-provider.htmlThe OVS I am using on the Compute Node, is compiled with DPDK, and I have enabled the datapath to netdev (DPDK) on br-prv (provider network bridge), and br-tun (tunneling bridge). But these two bridges, br-tun and br-prv, are patched into another OpenStack bridge, called br-int. I wasn’t actually sure about whether to tinker with this bridge, and wondered what datapath it was using.Then, I realized there is a parameter in the openvswitch_agent.ini file, which I will list here: # OVS datapath to use. 'system' is the default value and corresponds to the # kernel datapath. To enable the userspace datapath set this value to 'netdev'. # (string value) # Possible values: # system - <No description provided> # netdev - <No description provided> #datapath_type = system datapath_type = netdev So in tinkering with this, what I realized, is that when you set this datapath_type to system or netdev, it will adjust the br-int bridge to that datapath type.So here is my question. How can I launch a non-DPDK VM, if all of the bridges are using the netdev datapath type?Here is another question. What if one of the flavors don’t have the largepages property set on them? I assumed OpenStack would revert to a system datapath and not use DPDK for those VM interfaces. Well, I found out in testing, that is not the case. If you set all your bridges up for netdev, and you don’t set the property on the Flavor of the VM (largepages), the VM will launch, but it simply won’t work.Is there no way, on a specific Compute Host, to support both DPDK (netdev datapaths) and non-DPDK (system datapaths)?Either on a VM interface level (VM has one interface that is netdev DPDK and another that is system datapath non-DPDK)?Or on a VM by VM basis (VM 1 has 1 or more netdev datapath interfaces and VM 2 has 1 or more system datapath interfaces)?Am I right here? Once you set up a Compute Host for DPDK, it’s DPDK or nothing on that Compute Host? (edited)

3 2

How to config DPDK compute in OVN
by dangerzone ar 22 Apr '25

22 Apr '25

Hi....as far I understand ovs does support dpdk compute to be deployed. I'm referring to the guideline ' *https://docs.openstack.org/networking-ovn/queens/admin/dpdk.html <https://docs.openstack.org/networking-ovn/queens/admin/dpdk.html>* ' ... It's too brief.. May I know how to config dpdk compute in OVN networking openstack? Hope someone could help what is the config to be done.... Currently compute is run without dpdk over openstack train ovn based. Please need some info on how I can proceed. Thank you

2 1

ERROR openstack [-] Resource OS::TripleO::Network::Ports::ControlPlaneVipPort maps to type OS::Neutron::Port and the Neutron service is not available when using ephemeral Heat.| Openstack tripleo wallaby version
by Swogat Pradhan 23 Dec '24

23 Dec '24

Hi, I am currently trying to deploy openstack wallaby using tripleo arch. I created the network jinja templates, ran the following commands also: #openstack overcloud network provision --stack overcloud --output networks-deployed-environment.yaml custom_network_data.yaml # openstack overcloud network vip provision --stack overcloud --output vip-deployed-environment.yaml custom_vip_data.yaml # openstack overcloud node provision --stack overcloud --overcloud-ssh-key /home/stack/sshkey/id_rsa overcloud-baremetal-deploy.yaml and used the environment files in the openstack overcloud deploy command: (undercloud) [stack@hkg2director ~]$ cat deploy.sh #!/bin/bash THT=/usr/share/openstack-tripleo-heat-templates/ CNF=/home/stack/ openstack overcloud deploy --templates $THT \ -r $CNF/templates/roles_data.yaml \ -n $CNF/workplace/custom_network_data.yaml \ -e ~/containers-prepare-parameter.yaml \ -e $CNF/templates/node-info.yaml \ -e $CNF/templates/scheduler-hints.yaml \ -e $CNF/workplace/networks-deployed-environment.yaml \ -e $CNF/workplace/vip-deployed-environment.yaml \ -e $CNF/workplace/overcloud-baremetal-deployed.yaml \ -e $CNF/workplace/custom-net-bond-with-vlans.yaml Now when i run the ./deploy.sh script i encounter an error stating: ERROR openstack [-] Resource OS::TripleO::Network::Ports::ControlPlaneVipPort maps to type OS::Neutron::Port and the Neutron service is not available when using ephemeral Heat. The generated environments from 'openstack overcloud baremetal provision' and 'openstack overcloud network provision' must be included with the deployment command.: tripleoclient.exceptions.InvalidConfiguration: Resource OS::TripleO::Network::Ports::ControlPlaneVipPort maps to type OS::Neutron::Port and the Neutron service is not available when using ephemeral Heat. The generated environments from 'openstack overcloud baremetal provision' and 'openstack overcloud network provision' must be included with the deployment command. 2022-04-19 13:47:16.582 735924 INFO osc_lib.shell [-] END return value: 1 Can someone tell me where the mistake is? With regards, Swogat Pradhan

4 4

Live migration fails
by Szabo, Istvan (Agoda) 06 Aug '24

06 Aug '24

Hi, I have couple of compute nodes where the live migration fails with existing vms. When I quickly spawn a vm and try live migration it works so I assume shouldn't be a big problem with the compute node. However I have many existing vms where it fails with a servername not found. /var/log/nova/nova-conductor.log:2021-04-21 14:47:12.605 227612 ERROR nova.conductor.tasks.migrate [req-f4067a26-a233-4673-8c07-9a8a290980b0 dce35e6eceea4312bb0baa0510cef363 ca7e35079f4440c78bd9870724b9638b - default default] [instance: 1517a2ac-3b51-4d8d-80b3-89a5614d1ae0] Unable to find record for source node servername on servername: ComputeHostNotFound: Compute host servername could not be found. /var/log/nova/nova-conductor.log:2021-04-21 14:47:12.605 227612 WARNING nova.scheduler.utils [req-f4067a26-a233-4673-8c07-9a8a290980b0 dce35e6eceea4312bb0baa0510cef363 ca7e35079f4440c78bd9870724b9638b - default default] Failed to compute_task_migrate_server: Compute host servername could not be found.: ComputeHostNotFound: Compute host servername could not be found. /var/log/nova/nova-conductor.log:2021-04-21 14:47:12.605 227612 WARNING nova.scheduler.utils [req-f4067a26-a233-4673-8c07-9a8a290980b0 dce35e6eceea4312bb0baa0510cef363 ca7e35079f4440c78bd9870724b9638b - default default] [instance: 1517a2ac-3b51-4d8d-80b3-89a5614d1ae0] Setting instance to ACTIVE state.: ComputeHostNotFound: Compute host servername could not be found. /var/log/nova/nova-conductor.log:2021-04-21 14:47:12.672 227612 ERROR oslo_messaging.rpc.server [req-f4067a26-a233-4673-8c07-9a8a290980b0 dce35e6eceea4312bb0baa0510cef363 ca7e35079f4440c78bd9870724b9638b - default default] Exception during message handling: ComputeHostNotFound: Compute host am-osfecn-4025 Tried with this command: nova live-migration --block-migrate id. Any idea? Thank you. ________________________________ This message is confidential and is for the sole use of the intended recipient(s). It may also be privileged or otherwise protected by copyright or other legal rules. If you have received it by mistake please let us know by reply email and delete it from your system. It is prohibited to copy this message or disclose its content to anyone. Any confidentiality or privilege is not waived or lost by any mistaken delivery or unauthorized disclosure of the message. All messages sent to and from Agoda may be monitored to ensure compliance with company policies, to protect the company's interests and to remove potential malware. Electronic messages may be intercepted, amended, lost or deleted, or contain viruses.

5 16

[puppet] Proposing core team clean up
by Takashi Kajinami 23 Aug '23

23 Aug '23

Hello, I went through the current core reviewers and found out that the current list includes some people no longer working in the OpenStack community. I'd like to propose removing the following persons from the core reviewer team as we haven't seen these people making any activity in the community recently. * Pradeep Kilambi - puppet-aodh, puppet-ceilometer, puppet-gnocchi, puppet-panko * Richard Megginson - puppet-keystone * Denis Egorenko - puppet-murano * Serg Melikyan - puppet-murano * Sergey Kolekonov - puppet-neutron * David Moreau Simard - puppet-openstack-integration * Yu xingchao - all modules Also, I confirmed that Wes Hayutin is no longer working for OpenStack and he agreed to retire from the core reviewer position. Thus I'll remove him as well. I'll be open for any feedback for one week to hear any thoughts/feedback about this removal. I'd like to take this moment to thank all people for their past work. We always welcome them back if they resume their work in this project. Thank you, Takashi KAJINAMI

3 4

live resize
by Parsa Aminian 15 Mar '23

15 Mar '23

hello on openstack with ceph backend is it possible to live resize instances ? I want to change flavor without any down time .

5 6

[charms] Team Delegation proposal
by Chris MacNaughton 08 Feb '23

08 Feb '23

Hello All, <tl;dr> I would like to propose some new ACLs in Gerrit for the openstack-charms project: - openstack-core-charms - ceph-charms - network-charms - stable-maintenance </tl;dr> With an increasing focus split among the openstack-charmers team, I'm observing that people are focused on more specific subsets of the charms, and would like to propose that new ACLs are created to allow us to recognize that officially. I've chosen the breakdown above as it aligns neatly with where the focus lines are at this point, letting developers work on their specific focus areas. This proposal would not reduce permissions for anybody who is currently a core on the openstack-charms project and, in fact, future subteam core members could aspire to full openstack-charmers core as well. Ideally, this approach will let us escalate developers to "core" developers for the subteam(s) where they have demonstrated the expertise we expect in a core-charmer. It also allows a more gradual escalation to being a core in the openstack-charms project, making it a progression rather than a single destination. As a related addition, I'm appending to this proposal the creation of a stable-maintenance ACL which would allow members to manage backports without a full core-charmer grant. --- Chris MacNaughton

5 7

[cinder][drivers] third-party CI for os-brick changes
by Brian Rosmaita 04 Jan '23

04 Jan '23

To all third-party CI maintainers, As you are aware, cinder third-party CI systems are required to run on all cinder changes. However, the os-brick library used in cinder CI testing is the latest appropriate *released* version of os-brick. Thus, it is possible for changes to be happening in os-brick development that might impact the functionality of your driver. If you aren't testing os-brick changes, you won't find out about these until *after* the next os-brick release, which is bad news all around. Therefore, at last week's cinder midcycle [0], the cinder project team agreed to require that cinder third-party CI systems run on all os-brick changes in addition to all cinder changes. This is a nice-to-have for the current (Zed) development cycle, but will be required in order for a driver to be considered 'supported' in the 2023.1 (Antelope) release [1]. If you have comments or concerns about this policy, please reply on the list to this email or put an item on the agenda [2] for the cinder weekly meeting. [0] https://etherpad.opendev.org/p/cinder-zed-midcycles [1] https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers#What_changes… [2] https://etherpad.opendev.org/p/cinder-zed-meetings

2 1

Glance api deployed only on a single controller on multi-controller deployment [kolla]
by A Monster 30 Dec '22

30 Dec '22

I've deployed openstack xena using kolla ansible on a centos 8 stream cluster, using two controller nodes, however I found out after the deployment that glance api is not available in one node, I tried redeploying but I got the same behavior, although the deployment finished without displaying any error. Thank you. Regards

4 4

[all][TC] Bare rechecks stats week of 25.07
by Slawek Kaplonski 16 Dec '22

16 Dec '22

Hi, Here are fresh data about bare rechecks. +--------------------+---------------+--------------+-------------------+ | Team | Bare rechecks | All Rechecks | Bare rechecks [%] | +--------------------+---------------+--------------+-------------------+ | requirements | 2 | 2 | 100.0 | | keystone | 1 | 1 | 100.0 | | OpenStackSDK | 3 | 3 | 100.0 | | tacker | 3 | 3 | 100.0 | | freezer | 1 | 1 | 100.0 | | rally | 1 | 1 | 100.0 | | OpenStack-Helm | 14 | 15 | 93.33 | | cinder | 6 | 7 | 85.71 | | kolla | 20 | 25 | 80.0 | | neutron | 4 | 5 | 80.0 | | Puppet OpenStack | 10 | 13 | 76.92 | | OpenStack Charms | 3 | 6 | 50.0 | | nova | 11 | 22 | 50.0 | | tripleo | 8 | 19 | 42.11 | | ironic | 1 | 3 | 33.33 | | Quality Assurance | 1 | 3 | 33.33 | | octavia | 0 | 1 | 0.0 | | OpenStackAnsible | 0 | 1 | 0.0 | | designate | 0 | 1 | 0.0 | | Release Management | 0 | 1 | 0.0 | | horizon | 0 | 1 | 0.0 | +--------------------+---------------+--------------+-------------------+ Those data should be more accurate as my script now counts only comments from last 7 days, not all comments from patches updated in last 7 days. Reminder: "bare rechecks" are recheck comments without any reason given. If You need to do recheck for patch due to failed job(s), please first check such failed job and try to identify what was the issue there. Maybe there is already opened bug for that or maybe You can open new one and add it as explanation in the recheck comment. Or maybe it was some infra issue, in such case short explanation in the comment would also be enough. -- Slawek Kaplonski Principal Software Engineer Red Hat

6 10

[neutron] Switching the ML2 driver in-place from linuxbridge to OVN for an existing Cloud
by Christian Rohmann 26 Nov '22

26 Nov '22

Hello openstack-discuss and neutron experts, I'd like to ask for your input and discussion on the idea of changing the ML2 driver for an existing cloud, read: changing a tire while still riding the bike. I actually like to find out if it's feasible to switch from the trusted Linuxbridge driver to the more modern SDN stack of OVN - in place. With all existing user networks, subnets, security groups and (running) instances in the database already. And while I know there a push of migrating from OVS to OVN and a clear migration path documented (https://docs.openstack.org/neutron/latest/ovn/migration.html) but they are much more similar in their data plane. And to get this out of the way: I am not asking to do be able to do this without downtime, interruptions, migrations or any active orchestration of the process. I just want to know all the possible options apart from setting up a new cloud and asking folks to migrate all of their things over... 1) Are the data models of the user managed resources abstract (enough) from the ML2 used? So would the composition of a router, a network, some subnets, a few security group and a few instances in a project just result in a different instantiation of packet handling components, but be otherwise transparent to the user? 2) What could be possible migration strategies? While it might be a little early to think about the actual migration steps. But just to consider more than a full cloud shutdown following a cold start with modified neutron config then using the OVN ML2. I know there is more than just the network and getting a virtual layer 2 network. There are DHCP, DNS and the metadata service and last but not least the gateway / router and the security groups. But if using VXLAN for OVN (as Linuxbridge uses currently) could the shift from one implementation to the other potentially be done node by node? Or project by project by changing the network agents over to nodes already running OVN? If not, is there any other hot cut-over approach that would avoid having to shutdown all the instances, but only cause them some network downtime (until the next DHCP renew or similar?) Has anybody ever done something similar or heard about this being done anywhere? Thanks for your time and input, Christian

3 5

[designate] How to avoid NXDOMAIN or stale data during cold start of a (new) machine
by Christian Rohmann 23 Nov '22

23 Nov '22

Hello openstack-discuss, I have a designate setup using bind9 as the user-serving DNS server. When starting a machine with either very old or no zones at all, NXDOMAIN or other actually stale data is sent out to clients as designate is not done doing an initial full sync / reconciliation. * What is the "proper" way to tackle this cold-start issue and to keep the bind from serving wrong data? ** Did I miss on any options to handle this startup case? * What is the usual runtime for an initial sync that you observe in case the backend DNS server has no zones at all anymore? Regards Christian

2 7

Zun connector for persistent shared files system Manila
by Vaibhav 13 Nov '22

13 Nov '22

Hi, I am using zun for running containers and managing them. I deployed cinder also persistent storage. and it is working fine. I want to mount my Manila shares to be mounted on containers managed by Zun. I can see a Fuxi project and driver for this but it is discontinued now. With Cinder only one container can use the storage volume at a time. If I want to have a shared file system to be mounted on multiple containers simultaneously, it is not possible with cinder. Is there any alternative to Fuxi. is there any other mechanism to use docker Volume support for NFS as shown in the link below? https://docs.docker.com/storage/volumes/ Please advise and give a suggestion. Regards, Vaibhav

2 4

[all][tc] 2023.1 Antelope TC-PTG Planning
by Ghanshyam Mann 20 Oct '22

20 Oct '22

Hello Everyone, As you already know that the 2023.1 cycle virtual PTG will be held between Oct 17th - 21[1]. I have started the preparation for the Technical Committee PTG sessions. Please do the following: 1. Fill the below poll as per your availability. - https://framadate.org/yi8LNQaph5wrirks 2. Add the topics you would like to discuss to the below etherpad. - https://etherpad.opendev.org/p/tc-2023-1-ptg NOTE: this is not limited to TC members only; I would like all community members to fill the doodle poll and, add the topics you would like or want TC members to discuss in PTG. [1] https://lists.openstack.org/pipermail/openstack-discuss/2022-August/030041.… -gmann

2 4

[Ceilometer] Pollster cannot get RadosGW metrics when API endpoints are based on URL instead of port number
by Taltavull Jean-François 10 Oct '22

10 Oct '22

Hi All, In our OpenStack deployment, API endpoints are defined by using URLs instead of port numbers and HAProxy forwards requests to the right bakend after having ACLed the URL. In the case of our object-store service, based on RadosGW, the internal API endpoint is "https://<FQDN>/object-store/swift/v1/AUTH_<tenant_id>" When Ceilometer RadosGW pollster tries to connect to the RadosGW admin API with the object-store internal endpoint, the URL becomes https://<FQDN>/admin, as shown by HAProxy logs. This URL does not match any API endpoint from HAProxy point of view. The line of code that rewrites the URL is this one: https://opendev.org/openstack/ceilometer/src/branch/stable/wallaby/ceilomet… What would you think of adding a mechanism based on new Ceilometer configuration option(s) to control the URL rewriting ? Our deployment characteristics: - OpenStack release: Wallaby - Ceph and RadosGW version: 15.2.16 - deployment tool: OSA 23.2.1 and ceph-ansible Best regards, Jean-Francois

2 23

[ptg][edge]OpenStack at the Edge discussions
by Ildiko Vancsa 26 Sep '22

26 Sep '22

Hi, I’m reaching out to you in preparation to the upcoming PTG. The Edge Computing Group already started to prepare for the event and OpenStack came up during our conversations to have cross-project discussions with. The number of edge computing use cases in production is growing and OpenStack is a key infrastructure building block. Some edge related discussions regarding the project came up at previous PTGs and it would be great to continue and extend them. We covered areas in networking and looked into storage a little bit, and the question of finding a central place to store edge related documentation also came up. To identify new topics and follow up on ones we already started to discuss I added an OpenStack section to the Edge WG’s planning etherpad: https://etherpad.opendev.org/p/ecg-ptg-october-2022 If you are working on related features, have requirements or case studies to share, please add them to the above etherpad, so we can discuss them at the PTG and identify areas we can work together on to solve challenges and share information about exiting solutions. Please let me know if you have any questions or comments. Thanks, Ildikó

1 1

Cinder-volume active active setup
by Eugen Block 22 Sep '22

22 Sep '22

Hi, I didn't mean to hijack the other thread so I'll start a new one. There are some pages I found incl. Gorkas article [1], but I don't really understand yet how to configure it. We don't use any of the automated deployments (we created our own) like TripleO etc., is there any guide showing how to setup cinder-volume active/active? I see in my lab environment that python3-tooz is already installed on the control node, but how do I use it? Besides the "cluster" config option in the cinder.conf (is that defined when setting up the DLM?) what else is required? I also found this thread [2] pointing to the source code, but that doesn't really help me at this point. Any pointers to a how-to or deployment guide would be highly appreciated! Thanks, Eugen [1] https://gorka.eguileor.com/a-cinder-road-to-activeactive-ha/ [2] https://www.mail-archive.com/openstack@lists.openstack.org/msg18385.html

2 5

[all] Deprecated Zuul queue syntax
by Clark Boylan 16 Sep '22

16 Sep '22

Hello, Zuul deprecated declaring shared queues at a pipeline level with release 4.1.0 [0]. Zuul's current plan is to stop accepting this form of configuration with a future 7.0.0 release. More details on what needs to change can be found in Zuul's reminder notice on the Zuul mailing list [1]. I expect we have about a month before the v7 release which should give us plenty of time to fix this. If we don't fix this before the v7 release the expected fallout will be that these project branches will not have any pipelines defined, which means no Zuul jobs will run against that project branch until the configs are updated. I've marked this for everyone because 98 repositories are affected, and I'm not sure listing them all in the subject would be productive. Here is the list of affected repos: openstack/adjutant openstack/ansible-collection-kolla openstack/ansible-role-collect-logs openstack/ansible-role-tripleo-modify-image openstack/barbican openstack/barbican-tempest-plugin openstack/barbican-ui openstack/blazar openstack/blazar-tempest-plugin openstack/ceilometer openstack/cinderlib openstack/cloudkitty openstack/cloudkitty-tempest-plugin openstack/cyborg-tempest-plugin openstack/designate openstack/designate-dashboard openstack/designate-tempest-plugin openstack/devstack-gate openstack/ec2-api openstack/ec2api-tempest-plugin openstack/freezer openstack/freezer-tempest-plugin openstack/heat openstack/heat-dashboard openstack/heat-tempest-plugin openstack/horizon openstack/ironic openstack/ironic-inspector openstack/ironic-lib openstack/ironic-prometheus-exporter openstack/ironic-python-agent openstack/ironic-tempest-plugin openstack/kayobe openstack/kayobe-config openstack/kayobe-config-dev openstack/kolla openstack/kolla-ansible openstack/kuryr openstack/magnum openstack/magnum-tempest-plugin openstack/manila openstack/manila-tempest-plugin openstack/masakari openstack/masakari-monitors openstack/mistral openstack/mistral-tempest-plugin openstack/monasca-api openstack/monasca-common openstack/monasca-events-api openstack/monasca-log-api openstack/monasca-tempest-plugin openstack/murano openstack/murano-tempest-plugin openstack/networking-generic-switch openstack/octavia openstack/octavia-tempest-plugin openstack/openstack-chef openstack/os-net-config openstack/os-win openstack/oswin-tempest-plugin openstack/paunch openstack/project-config openstack/puppet-pacemaker openstack/puppet-tripleo openstack/python-designateclient openstack/python-ironicclient openstack/python-saharaclient openstack/python-tripleoclient openstack/python-troveclient openstack/sahara openstack/sahara-tests openstack/senlin openstack/senlin-tempest-plugin openstack/solum openstack/solum-tempest-plugin openstack/telemetry-tempest-plugin openstack/tenks openstack/tripleo-ci openstack/tripleo-ci-health-queries openstack/tripleo-common openstack/tripleo-heat-templates openstack/tripleo-quickstart openstack/tripleo-quickstart-extras openstack/tripleo-upgrade openstack/trove openstack/trove-tempest-plugin openstack/vitrage openstack/vitrage-tempest-plugin openstack/watcher openstack/watcher-tempest-plugin openstack/zaqar openstack/zaqar-tempest-plugin openstack/zun openstack/zun-tempest-plugin windmill/windmill windmill/windmill-backup x/neutron-classifier x/vmware-nsx I'll go ahead and push changes to windmill/* and x/* as those are leftovers from splitting things up into tenants and haven't ended up in their own tenants yet. But it would be great if OpenStack can work on cleaning up this deprecated syntax in the OpenStack repos. I've attached a file with a listing that includes more details for each repo (branches and specific config files) to make it easier for people to find where the old syntax is located so that it can be replaced with the new syntax. [0] https://zuul-ci.org/docs/zuul/latest/releasenotes.html#relnotes-4-1-0-depre… [1] https://lists.zuul-ci.org/pipermail/zuul-discuss/2022-May/001801.html

2 2

[ironic] Ilya Etingof Passed Away
by Iury Gregory 14 Sep '22

14 Sep '22

With a heavy heart, I am sorry to announce that after a long struggle with an illness, Ilya Etingof (etingof on IRC) passed away on Wednesday, 10th August, 2022. He is survived by his mother and two daughters. Born in Russia, Ilya had moved to Czechia and in 2015 joined Red Hat. In 2017, Ilya started contributing to the Ironic project. He was the lead contributor to the Sushy project, Sushy Redfish emulator, an important contributor to Ironic and worked tirelessly to make hardware management reliable and consistent. His important contributions included boot management, out-of-band hardware inspection and virtual media boot. Outside of the OpenStack community, he has maintained Python packages with a particular focus on SNMP. For example: pysnmp, pysmi, pyasn1, softboxen and many others. Ilya was dedicated to helping younger and under-represented people. He used to run a virtualisation technologies course at the Masaryk University in Brno where he spoke about OpenStack and Kubernetes. He was also an active participant in the Outreachy program where he mentored those who contributed to Open Source projects. Goodbye Ilya from the Ironic community, may you rest in peace. -- *Att[]'s* *Iury Gregory Melo Ferreira * *MSc in Computer Science at UFCG* *Ironic PTL * *Senior Software Engineer at Red Hat Brazil* *Social*: https://www.linkedin.com/in/iurygregory *E-mail: iurygregory(a)gmail.com <iurygregory(a)gmail.com>*

2 1

[all] GovStack community seeking for infrastructure expertise
by Lueck, Nico GIZ 10 Sep '22

10 Sep '22

Do you believe in the potential of digital public goods for positive impact? Ever wished for more digitally-enabled government services? GovStack [1] is a community-driven initiative on a mission to accelerate the digital transformation of government services in order to better serve citizens - and we want you to join us! We create and maintain an openly licenced blueprint for a modular architecture based on reusable building blocks [2]. Our various working groups work to define the (non-)functional and API specifications for building blocks, leveraging existing standards such as OpenStack. These specifications are then used for implementations in our partner countries across the world, to facilitate the delivery of foundational, life-enhancing services. Learn more about the call for contributions here [3]. We are specifically looking for experts with experience in infrastructure and security. The initiative is founded by the German Federal Ministry for Economic Cooperation and Development, Deutsche Gesellschaft fuer Internationale Zusammenarbeit (GIZ), the Ministry of Foreign Affairs of the Republic of Estonia, the International Telecommunication Union (ITU) and the Digital Impact Alliance. Thank you to the team of the Open Infrastructure Foundation for their support. Also, thank you to the whole community and please feel free to directly contact us. Nico (Lueck) <nico.lueck(a)giz.de> [1] https://www.govstack.global/ [2] https://govstack.gitbook.io/ [3] https://www.govstack.global/call-for-expression-of-interest/ ________________________________ Deutsche Gesellschaft fuer Internationale Zusammenarbeit (GIZ) GmbH; Sitz der Gesellschaft Bonn und Eschborn/Registered offices Bonn and Eschborn, Germany; Registergericht/Registered at Amtsgericht Bonn, Germany; Eintragungs-Nr./Registration no. HRB 18384 und/and Amtsgericht Frankfurt am Main, Germany; Eintragungs-Nr./Registration no. HRB 12394; USt-IdNr./VAT ID no. DE 113891176; Vorsitzender des Aufsichtsrats/Chairman of the Supervisory Board: Jochen Flasbarth; Vorstand/Management Board: Tanja Goenner (Vorstandssprecherin/Chair of the Management Board), Ingrid-Gabriela Hoven, Thorsten Schaefer-Guembel

3 2

[DIB][diskimage-builder] Rocky Linux image build method
by Pierre Riteau 07 Sep '22

07 Sep '22

Hello, I am curious about the choice of providing only a rocky-container element in DIB, which works differently to the centos element, which uses cloud images. It makes it hard to produce working images for VMs or bare metal, as various packages that would normally be installed are missing, such as cloud-utils-growpart or openssh-server. See the kickstarts for reference [1] [2]. It seems to also occasionally cause complex failures such as the one that rendered Rocky Linux 8 images unbootable last week [3]. I am guessing this wouldn't have happened had the build been from a cloud image. Would the DIB community be open to also have a rocky element using GenericCloud images, like centos? Thanks, Pierre Riteau (priteau) [1] https://git.rockylinux.org/rocky/kickstarts/-/blob/r8/Rocky-8-Container-Bas… [2] https://git.rockylinux.org/rocky/kickstarts/-/blob/r8/Rocky-8-GenericCloud.… [3] https://review.opendev.org/c/openstack/diskimage-builder/+/851687

6 6

[election][tripleo] PTL Candidacy for Antelope cycle
by Rabi Mishra 06 Sep '22

06 Sep '22

Hi All, I would like to nominate myself for Antelope cycle TripleO PTL. As some of you would know, I have been part of the OpenStack community for a long time and have been a core contributor for TripleO and Heat. I have also served as Heat PTL for Ocata cycle. James has done a great job as PTL for the last few cycles. I would like to take the opportunity to thank him for all his effort and we all would agree that he needs a well deserved break. I am looking forward to take the opportunity to help the community to achieve some of the already planned goals and in-progress workstreams like standalone roles, multi-rhel and other challenges that come along the way. Also, as before, our focus would continue to be on review prioritization, in progress work streams and collaboration on common priorities. Regards, Rabi Mishra

9 8

[manila] LVM shares are unmounted on reboot
by Vaibhav 05 Sep '22

05 Sep '22

Dear All, One of the host running Manila-share service has rebooted. After the reboot the LVMs are not mounted on the Manila mount points. I use LVM Driver with DHSS=False. default_share_type = default_share_type share_name_template = manila-%s rootwrap_config = /etc/manila/rootwrap.conf api_paste_config = /etc/manila/api-paste.ini auth_strategy = keystone my_ip=192.168.82.2 enabled_share_backends = lvm enabled_share_protocols = NFS state_path=/var/lib/manila [lvm] share_backend_name = LVM share_driver = manila.share.drivers.lvm.LVMShareDriver driver_handles_share_servers = False lvm_share_volume_group = VGZunManila lvm_share_export_ips = 192.168.82.2 lvm_share_export_root = $state_path/mnt After the reboot LVMs are there but they are mounted on their respective share location. Any way to solve this and this to be done automatically? Regards, Vaibhav

2 2

[tc][ptl] TC + Community Leaders interaction in 2023.1 Antelope Virtual PTG
by Ghanshyam Mann 02 Sep '22

02 Sep '22

Hello Everyone, We had successful TC+Community leaders interaction sessions in the last couple of PTG, and we will continue the same for 2023.1 cycle PTG also. I have created the poll to select the best suitable time. It will be for two hours (single or two sessions) either on Monday or Tuesday. Please add your preference in the below doodle poll (including TC members): - https://framadate.org/zsOqRxfVcmtjaPBC Also, I have created the below etherpad with the draft agenda, If you as PTL or project representatives or SIG Chair and would like to attend this session, please add your name: - https://etherpad.opendev.org/p/tc-leaders-interaction-2023-1 -gmann

1 1

[PTL][release] Zed Cycle Highlights
by Előd Illés 02 Sep '22

02 Sep '22

Hi, This is a reminder, that *this week* is the week for Cycle highlights [1][2]! They need to be added to deliverable yamls so that they can be included in release marketing preparations. (See the details about how to add them at the project team guide [3].) [1]https://releases.openstack.org/zed/schedule.html [2]https://releases.openstack.org/zed/schedule.html#z-cycle-highlights [3] https://docs.openstack.org/project-team-guide/release-management.html#cycle… Thanks, Előd Illés irc: elodilles

4 6

[heat][elections] PTL Candidacy for Antelope Cycle
by Brendan Shephard 02 Sep '22

02 Sep '22

Hi all, I first wanted to thank Rico for his ongoing commitment to the project over the last cycles. He has provided lots of guidance and help to the Heat project for a long time and his contribution deserves recognition. I am proposing my candidacy for Heat PTL during the Antelope cycle. I have worked with the Heat project for several years both as a user and more recently over the last 2 years as a contributor. I see great potential in the project for our users and look forward to continuing work in order to support features and functionality of the project. Some of my objectives for the next few cycles are: Remove the dependencies on legacy python-*client libraries and instead shift to the openstacksdk client library. While the legacy libraries have served us well, they are starting to show their limitations and the delta in servicibilty will only increase as each project moves towards leveraging the openstacksdk. So this change, while quite extensive will ensure future compatibility with the other OpenStack project teams. Continue ensuring Heat supports the most up-to-date and recent features provided by each project. To ensure Heat is the default and best choice for our users, we need to ensure we are able to leverage the latest available features from the complimentary OpenStack projects. This is an ongoing challenge to stay up-to-date with the changes each cycle and work towards implementing them in Heat. Thank you all for you consideration, and I look forward to the next cycle and continuing to work with you all. Regards, Brendan

3 2

[all] [oslo.messaging] Interest in collaboration on a NATS driver
by Tobias Urdin 01 Sep '22

01 Sep '22

Hello everyone, Before continuing on, yes this kind of is a massive effort but it doesn’t have to be, it would be very cool to get a replacement for RabbitMQ as I’m probably not the only one not satisfied with it. I've proposed a very bare POC in [1] but it's long way from being finished, but atleast some basic devstack is passing. NATS [2] is a cloud-native scalable messaging system that supports the one-to-many and pub-sub methods that we can use to implement it as a oslo.messaging driver. This would make OpenStack easier to deploy in a highly available fashion, reduce outages related to RabbitMQ, free up memory and CPU usage by RabbitMQ (it’s insane when using clustering) and embrace a more cloud-native approach for our software that runs the cloud, alternatives is also welcome :) The POC has a lot of things that could be improved for example: • Do retries and acknowledgements in the library (since NATS does NOT persist messages like RabbitMQ could) • Handle reconnects or interruptions (for example resubscribe to topics etc) • Timeouts need to be implemented and handled • Investigate maximum message payload size • Find or maintain a NATS python library that doesn't use async like the official one does • Add a lot of testing • Cleanup everything noted as TODO in the POC code Now I couldn’t possibly pull this off myself without some collaboration with all of you, even though I’m very motivated to just dig in and do this for the rest of the year and migrate our test fleet there I unfortunately (like everyone else) is juggeling a lot of balls at the same time. If anybody, or any company, out there would be interested in collaborating in a project to bring this support and maintain it feel free to reach out. I’m hoping somebody will bite but atleast I’ve put it out there for all of you. Best regards Tobias [1] https://review.opendev.org/c/openstack/oslo.messaging/+/848338 [2] https://nats.io

4 7

[ovn-bgp-agent][neutron] - expose_tenant_networks bug
by Satish Patel 31 Aug '22

31 Aug '22

Folks, I am setting up ovn-bgp-agent lab in "BGP mode" and i found everything working great except expose tenant network https://ltomasbo.wordpress.com/2021/02/04/ovn-bgp-agent-testing-setup/ Lab Summary: 1 controller node 3 compute node ovn-bgp-agent running on all compute node because i am using "enable_distributed_floating_ip=True" ovn-bgp-agent config: [DEFAULT] debug=False expose_tenant_networks=True driver=ovn_bgp_driver reconcile_interval=120 ovsdb_connection=unix:/var/run/openvswitch/db.sock I am not seeing my vm on tenant ip getting exposed but when i attach FIP which gets exposed in loopback address. here is the full trace of debug logs: https://paste.opendev.org/show/buHiJ90nFgC1JkQxZwVk/

2 9

help: set ironic inspect autodiscovery failed
by 陈薇 31 Aug '22

31 Aug '22

Hi All, I'm trying the ironic inspect autodiscovery but failed. What I did: Set the inspector.conf 1. [discovery] enroll_node_driver = ipmi [processing] permit_active_introspection = true processing_hooks = $default_processing_hooks,extra_hardware,lldp_basic Configure the python agent: inspection_callback_url: There's no node automatically added. I enter the host and read the log of python agent, no inspect related log. Could anybody give any advice about how to triage or setup correctly? Thanks & Regards, Wei

1 1

[election][openstack-ansible] PTL candidacy for Antelope cycle
by Dmitriy Rabotyagov 31 Aug '22

31 Aug '22

Hello. I want to self-nominate for the role of OpenStack-Ansible PTL for the Antelope release cycle. As always, my goal will be to constantly improve existing code, make deployments and further operations as reliable as possible. For the previous cycle we have reached some of previously defined goals, like adding a `service` role, finally implementing service_token_roles and support of CentOS 9 Stream, but there is still room for improvement for role testing. With the return of live events I will do my best to ensure project presence on them and get in touch with operators to gain feedback for project future improvement. -- Kind regards, Dmitriy Rabotyagov

2 1

[all][tc] Technical Committee next weekly meeting on 2022 Sept 1 at 1500 UTC
by Ghanshyam Mann 31 Aug '22

31 Aug '22

Hello Everyone, Below is the agenda for Tomorrow's TC meeting schedule at 1500 UTC. https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting * Roll call * Follow up on past action items * Gate health check ** Bare 'recheck' state *** https://etherpad.opendev.org/p/recheck-weekly-summary * Checks on Zed cycle tracker ** https://etherpad.opendev.org/p/tc-zed-tracker * 2023.1 cycle PTG Planning ** TC + Leaders interaction sessions *** https://etherpad.opendev.org/p/tc-leaders-interaction-2023-1 ** TC PTG etherpad *** https://etherpad.opendev.org/p/tc-2023-1-ptg ** Schedule 'operator hours' as a separate slot in PTG(avoiding conflicts among other projects 'operator hours') *** https://twitter.com/osopsmeetup/status/1561708283492196353 *** https://doodle.com/meeting/participate/id/bD9kR2yd * 2023.1 cycle Technical Election ** https://governance.openstack.org/election/ * Open Reviews ** https://review.opendev.org/q/projects:openstack/governance+is:open -gmann

1 0

[cinder] Extending Feature Freeze Deadline by 1 week
by Rajat Dhasmana 31 Aug '22

31 Aug '22

Hi All, As discussed in the cinder meeting today, due to the abundance of features proposed[1] and the shortage of review bandwidth, we are planning to extend the feature freeze by one week. Current feature freeze date (for cinder): 01 September 2022 New feature freeze date (for cinder): 08 September 2022 Kindly let me know if there are any objections to the above proposal else all the features proposed are eligible for the feature freeze exception of 1 week. [1] https://etherpad.opendev.org/p/cinder-zed-features Thanks and regards Rajat Dhasmana

1 0

[election][manila] PTL Candidacy for Antelope cycle
by Carlos Silva 31 Aug '22

31 Aug '22

Greetings, Zorillas and interested stackers, I would like to announce my candidacy to be the Manila PTL during the Antelope cycle. I have been the PTL for Manila since the Zed cycle, and have been contributing to OpenStack since the Stein release. It has been an awesome experience. Over the Zed cycle my focus was to continue mentoring and adding new core reviewers to the Manila repositories; Pursuing feature parity and complete support for manila in OSC (also increasing our functional tests coverage), tackling the tech debt; enhancing the documentation to help third party drivers to set up their CI systems; promoting events to gather the community members and getting bugs fixed and implementations moving faster. I am happy with the progress we made in those areas, but I still think there is room for improvement. During the Antelope cycle, I would like to focus on: - Continue our efforts to mentor contributors and increase the amount of active reviewers through engaging them in the community, teaching the OpenStack way and making it collaboratively as we did in the past cycles, promoting hackathons, bug squashes and collaborative review sessions. - Getting more features already available in the Manila core to Manila UI and get more attention to our changes to OpenStack SDK; - Continue pushing Manila to cover the tech debt areas we identified over the past cycles; - Enforcing maintainers to collaboratively cover the lack of documentation we have on third party CI setups for Manila, helping potential new vendors to quickly setup up their CI systems; Thank you for your consideration! Carlos da Silva IRC: carloss

3 2

[cinder] Antelope PTG Planning
by Rajat Dhasmana 31 Aug '22

31 Aug '22

Hi All, The virtual PTG for Antelope/2023.1 cycle will be held between 17-21 October 2022. The proposed schedule for cinder is as follows: Dates: Tuesday (18th October) to Friday (21st October) 2022 Time: 1300 to 1700 UTC Etherpad: https://etherpad.opendev.org/p/antelope-ptg-cinder-planning Please add topics to the etherpad as early as possible since that will help arrange the topics day wise in the actual PTG etherpad. Thanks and regards Rajat Dhasmana

1 0

[QA][ironic] cycle-with-intermediary deliverables without any release
by Előd Illés 31 Aug '22

31 Aug '22

Hi, Quick reminder that we'll need a release very soon for a number of deliverables following a cycle-with-intermediary release model but which have not done *any* release yet in the Zed cycle: [ironic*] bifrost ironic-prometheus-exporter ironic-python-agent-builder ironic-ui networking-baremetal networking-generic-switch [Quality Assurance] patrole Those should be released ASAP, and in all cases before September 15th, so that we have a release to include in the final Zed release. (* actually, we DID discuss this already with Ironic release liaisons [1], so this is just a formal reminder for them) [1] https://meetings.opendev.org/irclogs/%23openstack-release/%23openstack-rele… Előd Illés irc: elodilles

1 0

[OVN] Error while creating a new instance due to port binding failure
by 박경원 31 Aug '22

31 Aug '22

1 0

[largescale-sig] Next meeting: August 31st, 15utc
by Thierry Carrez 31 Aug '22

31 Aug '22

Hi everyone, The Large Scale SIG is back from its extended vacation! We will be meeting this Wednesday in #openstack-operators on OFTC IRC, at 15UTC. You can check how that time translates locally at: https://www.timeanddate.com/worldclock/fixedtime.html?iso=20220831T15 Feel free to add topics to the agenda: https://etherpad.openstack.org/p/large-scale-sig-meeting Regards, -- Thierry Carrez

1 1

Take the OpenStack User Survey! Deadline Today!
by Allison Price 31 Aug '22

31 Aug '22

Hi everyone, I wanted to remind you that today is the last day to complete your 2022 OpenStack User Survey. If you (or a customer) is operating an OpenStack environment, please take time to complete the deployment survey. If you have completed it before, you will just need to update your information, but your previous responses will auto-populate. Complete here: https://www.openstack.org/usersurvey <https://www.openstack.org/usersurvey> Please let me know if you have any issues. Cheers, Allison

1 0

[charms] Nominate Luciano Giudice for charms-ceph core
by Chris MacNaughton 31 Aug '22

31 Aug '22

Hello all, I'd like to propose Luciano as a new Ceph charms core team member. He has contributed quality changes over the last year, and has been providing quality reviews for the Ceph charms. patches: https://review.opendev.org/q/owner:luciano.logiudice%2540canonical.com reviews: https://review.opendev.org/q/reviewedby:luciano.logiudice%2540canonical.com I hope you will join me in supporting Luciano. Chris MacNaughton

4 3

[election][cloudkitty] PTL candidacy for Antelope
by Rafael Weingärtner 31 Aug '22

31 Aug '22

Hi all, I would like to self-nominate for the role of PTL of CloudKitty for the Antelope release cycle. I have been PTL since the Victoria cycle and I am willing to continue in this role. I will keep working with existing contributors to maintain CloudKitty for their use cases and encourage the addition of new functionalities. -- Rafael Weingärtner

1 0

[cinder] Bug deputy report for week of 08-31-2022
by Sofia Enriquez 31 Aug '22

31 Aug '22

This is a bug report from 08-24-2022 to 08-31-2022. Agenda: https://etherpad.opendev.org/p/cinder-bug-squad-meeting ----------------------------------------------------------------------------------------- Low - https://bugs.launchpad.net/cinder/+bug/1987539 "DeprecationWarning: Flags not at the start of the expression." Fix proposed to master. Cheers, Sofia -- Sofía Enriquez she/her Software Engineer Red Hat PnT <https://www.redhat.com> IRC: @enriquetaso @RedHat <https://twitter.com/redhat> Red Hat <https://www.linkedin.com/company/red-hat> Red Hat <https://www.facebook.com/RedHatInc> <https://www.redhat.com>

1 0

[election][Octavia] PTL candidacy for Antelope cycle
by Gregory Thiemonge 31 Aug '22

31 Aug '22

Hi, I would like to announce my candidacy for Octavia PTL for the Antelope release. I have been PTL since the Xena cycle and I want to continue to contribute to this role. During the Antelope cycle we will focus on reviewing/merging some of the opened patches we still have in our backlog (we are a small team but we have been growing, we expect that we will be more efficient in merging patches). For the A cycle we also need to work on the migration to sqlalchemy 2, it will be a huge challenge for our team. Thanks for your consideration, Gregory Thiemonge (gthiemonge)

1 0

[all][elections][ptl][tc] Combined PTL/TC antelope cycle Election Nominations Extended 7 days
by Amy Marrich 31 Aug '22

31 Aug '22

We have extended the nomination period 7 days and will overlap the TC campaigning period to accommodate the extension. Thank you everyone who has nominated themselves and for cutting down the list of leaderless projects to 24. Remember there are also 4 open seats for the TC this election cycle which the automated email does not include in this reminder. Thanks, Amy ---------------------------------------------------------------------------------------------- A quick reminder that we are in the last hours for declaring PTL and TC candidacies. Nominations are open until Sep 07, 2022 23:45 UTC. If you want to stand for election, don't delay, follow the instructions at [1] to make sure the community knows your intentions. Make sure your nomination has been submitted to the openstack/election repository and approved by election officials. Election statistics[2]: Nominations started @ 2022-08-24 23:45:00 UTC Nominations end @ 2022-09-07 23:45:00 UTC Nominations duration : 14 days, 0:00:00 Nominations remaining : 7 days, 10:19:33 Nominations progress : 46.93% --------------------------------------------------- Projects[1] : 52 Projects with candidates : 28 ( 53.85%) Projects with election : 0 ( 0.00%) --------------------------------------------------- Need election : 0 () Need appointment : 24 (Adjutant Barbican Cloudkitty Keystone Masakari Mistral Octavia OpenStackAnsible OpenStackSDK OpenStack_Charms Openstack_Chef Oslo Quality_Assurance Rally Release_Management Requirements Sahara Senlin Skyline Swift Trove Venus Zaqar Zun) =================================================== Stats gathered @ 2022-08-31 13:25:27 UTC This means that with approximately 7 days left, 24 projects will be deemed leaderless. In this case the TC will oversee PTL selection as described by [3]. Thank you, [1] https://governance.openstack.org/election/#how-to-submit-a-candidacy [2] Any open reviews at https://review.openstack.org/#/q/is:open+project:openstack/election have not been factored into these stats. [3] https://governance.openstack.org/resolutions/20141128-elections-process-for…

1 0

[openstack-ansible] Converged compute ans ceph storage
by fv＠spots.edu 31 Aug '22

31 Aug '22

Hello everyone! Is it possible with OpenStack-Ansible to deploy converged nova compute and ceph storage on a single node? Thank you!

3 2

[openstack-ansible][ceph][yoga] wait for all osd to be up
by Father Vlasie 31 Aug '22

31 Aug '22

Hello everyone, I am running setup-infrastucture.yml. I have followed the ceph production example here: https://docs.openstack.org/openstack-ansible/latest/user/ceph/full-deploy.h… I have set things up so the compute and storage nodes are the same machine (hyperconverged). And the storage devices are devoid of any volumes or partitions. I see the following error: ------ FAILED - RETRYING: [compute3 -> infra1_ceph-mon_container-0d679d8d]: wait for all osd to be up (1 retries left). fatal: [compute3 -> infra1_ceph-mon_container-0d679d8d(192.168.3.145)]: FAILED! => {"attempts": 60, "changed": false, "cmd": ["ceph", "--cluster", "ceph", "osd", "stat", "-f", "json"], "delta": "0:00:00.223291", "end": "2022-08-22 19:36:29.473358", "msg": "", "rc": 0, "start": "2022-08-22 19:36:29.250067", "stderr": "", "stderr_lines": [], "stdout": "\n{\"epoch\":6,\"num_osds\":0,\"num_up_osds\":0,\"osd_up_since\":0,\"num_in_osds\":0,\"osd_in_since\":0,\"num_remapped_pgs\":0}", "stdout_lines": ["", "{\"epoch\":6,\"num_osds\":0,\"num_up_osds\":0,\"osd_up_since\":0,\"num_in_osds\":0,\"osd_in_since\":0,\"num_remapped_pgs\":0}”]} ------ I am not sure where to look to find more information. Any help would be much appreciated! Thank you, FV

2 2

[election][designate] PTL Candidacy for Antelope cycle
by Michael Johnson 30 Aug '22

30 Aug '22

Hello OpenStack community, I would like to announce my candidacy for PTL of Designate for the Antelope cycle. I would like to continue to support the Designate team for the Antelope release. As predicted, we have continued to focus on cleaning up technical debt and improving the test coverage. For a small team, we have accomplished a lot in the Zed release, though we could use more reviewers to help with the backlog of patches in need of review and comments. I expect the code cleanup will continue, but I hope we can also focus more on some of the proposed features that are in flight. Thank you for your support and your consideration for Antelope, Michael Johnson (johnsom)

1 0

[cinder] propose to EOL cinderlib train and ussuri
by Brian Rosmaita 30 Aug '22

30 Aug '22

At last week's cinder project midcycle [0], the team discussed recent fixes to keep the cinderlib CI functional in the oldest stable branches. At this point, stable/train is running the bare minimum of CI to keep the branch open, and stable/ussuri is running only one functional job in excess of the bare minimum. The only changes merged into either branch since each was tagged -em have been non-functional, so we believe that there is no demand for keeping the branches open. Thus, the following patches to EOL cinderlib train and ussuri have been posted: - https://review.opendev.org/c/openstack/releases/+/853534 - https://review.opendev.org/c/openstack/releases/+/853535 This email serves as notice of the intent of the cinder project to EOL the cinderlib train and ussuri branches. If you have comments or concerns, please reply to this email or leave a comment on the appropriate patch. [0] https://etherpad.opendev.org/p/cinder-zed-midcycles

1 1

[blazar][election] PTL candidacy for Antelope cycle
by Pierre Riteau 30 Aug '22

30 Aug '22

Hi, I would like to self-nominate for the role of PTL of Blazar for the Antelope release cycle. I have been PTL since the Stein cycle and I am willing to continue in this role. Though we had a quiet Zed cycle, we still have various improvements in the pipeline and I want to help the community deliver them to make Blazar more useful. Thank you for your support, Pierre Riteau (priteau)

1 0

[election][puppet] PTL Candidacy for Antelope cycle
by Takashi Kajinami 30 Aug '22

30 Aug '22

Hello, I'd like to announce my candidacy for the PTL role in Puppet OpenStack, to continue my PTL role for the Antelope cycle. Over the past two cycles, we've successfully improved feature coverage, platform coverage and simplicity of our modules. I'd like to list up a few items which would be our priorities during the next cycle. * Add Ubuntu 22.04 support This would be the next major change after we've completed implementation of CentOS 9 Stream support. We already adapted to Ruby 3 as part of C9S support so I'm not aware of any huge challenges at this moment. * Complete migration to Puppet 7 Currently our modules still support both Puppet 6 and 7. However once we complete migration to Ubuntu 22.04, we complete migration from Ruby 2.x to 3.x. As Puppet officially supports Ruby 3.x since 7.7, this means we no longer maintain test coverage with Puppet 6. It's time to consider again complete migration to Puppet 7. * Improve scenario/component coverage by CI During Zed cycle we added OVN and Octavia to the integration jobs. We'll review a few remaining modules like Manila and will continue extending the component coverage. * Review unmaintained/unused modules In Puppet OpenStack projects we maintain number of modules to support multiple OpenStack components. However, some modules have not been really active and attracted no interest. In the past few cycles we have retired several modules but I'd like to continue reviewing our modules to consider retiring inactive ones. * Keep each module up to date and simple It's always important that we add support for the new features/parameters timely so that users can leverage the new capability via our modules. Thank you for your consideration. Thank you, Takashi

3 2

[election][cinder] PTL Candidacy for Antelope
by Rajat Dhasmana 30 Aug '22

30 Aug '22

Hello everyone, I would like to announce my candidacy for PTL of the Cinder project for the Antelope cycle. I served as the PTL for Cinder during the Zed development cycle and targeted some of the areas which were lacking attention and worked on improving them like: 1. Review Quality Proposing the Efficient Review Guidelines[1] to help new contributors improve the quality of reviews. 2. Security Vulnerabilities Triaged the open security issues during the first mid cycle[2]. There are still areas which could be improved upon like 3rd Party Compliance checks and Cinder driver documentation which are good candidates of work items for the next development cycle and I look forward to actively work on them. Apart from that, there were deadlines which could have been better handled which I would like to incorporate in my planning skills so we get things merged in time and we won't have to extend deadlines frequently. Overall, I feel it was a good learning experience being PTL for the first time and I'm thankful for all the support I've had from the team, not to mention the advice and help from Brian while making critical decisions, and Hopefully I will take the learnings to be a better PTL this time. [1] https://docs.openstack.org/cinder/latest/contributor/gerrit.html#efficient-… [2] https://etherpad.opendev.org/p/cinder-zed-midcycles#L136 Rajat Dhasmana (whoami-rajat)

1 0