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

[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 11 Sep '22

11 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