February 2022 - openstack-discuss

bypass sphinx conf.py from CLI
by Stone, Ronald 03 Feb '22

03 Feb '22

Hi, The StarlingX docs team is implementing the default sphinxcontrib.spelling spelling extension for use from tox via a virtualenv set up for this purpose. We do not want sphinxcontrib.spelling loaded into other tox jobs that won't use it. This means that it cannot be loaded from the standard conf.py. Instead I am bypassing conf.py and setting parameters from the sphinx-build command in the appropriate tox job: sphinx-build -a -E -C --keep-going -d doc/build/doctrees -D extensions=sphinxcontrib.spelling -D spelling_word_list_filename=spelling_wordlist.txt -D rst_prolog="open('./shared/strings.txt', 'r').read()" -t starlingx -t openstack -b spelling doc/source doc/build/spelling {posargs} This works except that we also need to load some strings into the rst prolog for various purposes, and that is failing without warning or errors. I can open the file from a python console. Sphinx-build escapes the single quotes as: open('"'"'./shared/strings.txt'"'"', '"'"'r'"'"').read()' Any suggestions on the correct parameter format appreciated. Ron

3 2

[os-brick][nova][cinder][glance] Question about lock_path
by Radosław Piliszek 03 Feb '22

03 Feb '22

Hello Fellow OpenStackers! I have noticed os-brick started using the file locks (in lock_path) to avoid race conditions. I have a question regarding that lock_path - it seems all the cases I have found use separate lock_paths per service, yet the problematic cases listed in the bug report (and the commit message of [1]) suggest that, in case of co-hosted nova-compute, glance-api, cinder-volume and cinder-backup services (or any combination thereof), the lock_path should be shared. Should the deployment projects adapt to actually fix the race condition issue? [1] https://review.opendev.org/c/openstack/os-brick/+/814139 Kind regards, -yoctozepto

4 7

[stein][neutron] Static rules losed
by Gargano Andrea 03 Feb '22

03 Feb '22

Hi all, we faced an inssue in our openstack, we have some private clouds with static rules, if the controller that own namespace with the static rule goes down, namespace moves to other controller but it loses the rule. I can still see the rules inside the router on openstack but it doesn't work until recreated. Have you seen something like this? Thank you in advance. Andrea Gargano

1 1

[all][tc] Technical Committee next weekly meeting is today (Feb 3rd) at 1500 UTC
by Radosław Piliszek 03 Feb '22

03 Feb '22

Hello OpenStackers, Below is the agenda for today's TC IRC meeting scheduled at 1500 UTC. https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting == Agenda for today's TC meeting == * Roll call * Follow up on past action items * Gate health check ** Fixing Zuul config error in OpenStack *** https://etherpad.opendev.org/p/zuul-config-error-openstack * Progress check on Yoga tracker ** https://etherpad.opendev.org/p/tc-yoga-tracker * Z Release Cycle Name ** Election results: https://civs1.civs.us/cgi-bin/results.pl?id=E_693bd8bbe63ca52f ** Next step, the foundation has started the trademark checks. * Z cycle Technical Elections ** Proposed Election schedule, need to merge it if no objection. *** https://review.opendev.org/c/openstack/election/+/825017 * Open Reviews ** https://review.opendev.org/q/projects:openstack/governance+is:open -yoctozepto

1 0

[cinder][drivers] stable branch backports
by Brian Rosmaita 02 Feb '22

02 Feb '22

Hello Argonauts, especially vendor driver maintainers: At last week's midcycle meeting, we began a discussion of running third-party CI on stable branch changes. While that continues *not* to be required (it will be re-visited at the Z PTG), we did agree to the following: When a vendor driver patch backport is proposed, we would like to see a clear statement on the gerrit review that the patch has been tested in an appropriate environment. This shouldn't be a big deal because presumably you've done local testing with your backend to ensure that the code works as expected in a stable branch; we're simply asking that this be documented on the backport. cheers, brian

1 0

RE: Openstack VLAN provider Network
by DHilsbos＠performair.com 02 Feb '22

02 Feb '22

Felipe; A lot of this will depend on how you have Neutron configured. We use OpenVSwitch. For OpenVSwitch you want a completely unconfigured interface, for VLANs. If you haven't looked at Server World's tutorial for OpenStack, I would suggest you do so. They can be found here: https://www.server-world.info/en/note?os=Ubuntu_20.04&p=openstack_xena2&f=6 https://www.server-world.info/en/note?os=CentOS_Stream_8&p=openstack_xena2&… Pay particular attention to the names br-eth1 and physnet1, and where and how they are used. You are likely going to need to reference the "Configure Neutron #2" page from the tutorial to understand the whole configuration, as these assume #1 and #2 have been completed (#1 walks through how to setup the support services). The tutorials are for VXLAN, but are modifiable to be VLAN. In particular; [ml2_type_vxlan] vni_ranges = 1:1000 becomes: [ml2_type_vlan] network_vlan_ranges = physnet1:1:1000 For you, I believe that last line would be: network_vlan_ranges = physnet1:684:684 What I can't help you with is how this interacts with PackStack. Thank you, Dominic L. Hilsbos, MBA Vice President – Information Technology Perform Air International Inc. DHilsbos(a)PerformAir.com www.PerformAir.com From: Felipe Mogollon [mailto:fmogollon@vicomtech.org] Sent: Wednesday, February 2, 2022 12:44 AM To: Dominic Hilsbos Subject: Re: Openstack VLAN provider Network Do you mean to remove only ip address from VLAN's eth configuration or removing all VLAN's eth configuration? Thanks Felipe On Wed, Feb 2, 2022 at 12:21 AM <DHilsbos(a)performair.com> wrote: Felipe; I had significant problems with this as well, when I was first setting up our cluster. The first thing to recognize is that the network type is from the stand point of the host (more specifically from the network services host, and the neutron compute hosts), not the network itself. Your VLAN network is actually a physical network (from the standpoint of the host), because it is bound to a physical interface. If you want to actually use it as a vlan type; a) remove the IP address(es) from the interface(s) of the network and compute host(s), and b) properly configure ml2, or an equivalent plugin. Thank you, Dominic L. Hilsbos, MBA Vice President – Information Technology Perform Air International Inc. DHilsbos(a)PerformAir.com www.PerformAir.com From: Felipe Mogollon [mailto:fmogollon@vicomtech.org] Sent: Tuesday, February 1, 2022 7:49 AM To: openstack-discuss Subject: Openstack VLAN provider Network I have deployed an OpenStack Victoria using packstack in a Centos 8 Stream machine. I have 3 NIC interfaces that are configured in the following way eno1 -> VLAN 684 10.15.0.0/16 eno2 -> local network 192.168.235.0/24 eno3 -> local network 192.168.15.0/24 VLAN and local networks are working fine outside Openstack. I have deployed Openstack using packstack and local networks work fine and I can deploy instances inside openstack that get floating ips from those ranges without problem and I can ping to them. The problem is with VLAN network, I can deploy instances and I get floating ips from VLAN network range but I can't ping them. My packstack answer file is https://pastebin.com/GEqspMWu I have created VLAN network using following commands: neutron net-create vlan_network --provider:network_type vlan --provider:physical_network vlan --router:external=True --shared --provider:segmentation_id=684 neutron subnet-create --name vlan_subnet --enable_dhcp=False --allocation-pool=start=10.15.11.103,end=10.15.11.113 --gateway=10.15.11.1 vlan_network 10.15.11.0/24 Any ideas? -- Juan Felipe Mogollón Rodríguez Researcher | Investigador fmogollon(a)vicomtech.org +[34] 943 30 92 30 Digital Media member of: La información que contiene este mensaje y sus adjuntos son confidenciales y están dirigidos exclusivamente a sus destinatarios. Si recibe este mensaje por error, se ruega nos lo comunique y proceda a su borrado. The information contained in this electronic message is intended only for the personal and confidential use of the recipients designated in the original message. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer.

2 1

Openstack VLAN provider Network
by Felipe Mogollon 02 Feb '22

02 Feb '22

I have deployed an OpenStack Victoria using packstack in a Centos 8 Stream machine. I have 3 NIC interfaces that are configured in the following way eno1 -> VLAN 684 10.15.0.0/16 eno2 -> local network 192.168.235.0/24 eno3 -> local network 192.168.15.0/24 VLAN and local networks are working fine outside Openstack. I have deployed Openstack using packstack and local networks work fine and I can deploy instances inside openstack that get floating ips from those ranges without problem and I can ping to them. The problem is with VLAN network, I can deploy instances and I get floating ips from VLAN network range but I can't ping them. My packstack answer file is https://pastebin.com/GEqspMWu I have created VLAN network using following commands: neutron net-create vlan_network --provider:network_type vlan --provider:physical_network vlan --router:external=True --shared --provider:segmentation_id=684 neutron subnet-create --name vlan_subnet --enable_dhcp=False --allocation-pool=start=10.15.11.103,end=10.15.11.113 --gateway=10.15.11.1 vlan_network 10.15.11.0/24 Any ideas? -- <https://www.vicomtech.org> Juan Felipe Mogollón Rodríguez Researcher | Investigador fmogollon(a)vicomtech.org +[34] 943 30 92 30 Digital Media <https://www.linkedin.com/company/vicomtech> <https://www.youtube.com/user/VICOMTech> <https://twitter.com/@Vicomtech> member of: <https://graphicsvision.ai/> La información que contiene este mensaje y sus adjuntos son confidenciales y están dirigidos exclusivamente a sus destinatarios. Si recibe este mensaje por error, se ruega nos lo comunique y proceda a su borrado. The information contained in this electronic message is intended only for the personal and confidential use of the recipients designated in the original message. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer.

3 4

[TripleO] Gate blocker - opstools repo
by Ronelle Landy 02 Feb '22

02 Feb '22

Hello All, We have an issue with tripleo-ci-centos-8-content-provider <https://zuul.opendev.org/t/openstack/build/b05d7482835f4b4d83180c29b12973b0> among other tests failing in check/gate due to missing 'centos-opstools' repo. Details are in: https://bugs.launchpad.net/tripleo/+bug/1959619. There are a few patch in flight to try address this issue: https://review.rdoproject.org/r/c/rdo-infra/ansible-role-dlrn/+/38673 - Use opstools packages from trunk.rdoproject.org in cs8 https://review.opendev.org/c/openstack/tripleo-quickstart/+/827111/ - Adds temporary rdoproject repo for collectd/opstools Centos-8 Please hold rechecks until we manage to merge the fixes. Thank you!

2 3

[Diversity] Diversity and Inclusion Meeting Reminder - New Day, Time and Location
by Amy Marrich 02 Feb '22

02 Feb '22

The Diversity & Inclusion WG invites members of all OIF projects to attend our next meeting Friday February 4th, at 15:00 UTC on https://meetpad.opendev.org/osf-diversity-and-inclusion. The agenda can be found at https://etherpad.openstack.org/p/diversity-wg-agenda. Please feel free to add any topics you wish to discuss at the meeting. Thanks, Amy (apotz)

1 0

[all][infra][qa][tripleo][openstack-ansible][rally][aodh][cinder][kolla][chef][sahara] CentOS 8 EOL and removal from CI label/image lists
by Clark Boylan 01 Feb '22

01 Feb '22

As noted last month the OpenDev [0] team intends on removing CentOS 8 images from our CI system now that the release has gone EOL. A number of you have already shifted over to CentOS 8 Stream in CI (thank you!), but there is still quite a bit remaining based on codesearch and some manual digging. The OpenDev team has begun the process of removing some of the supporting infrastructure and testing as well [1]. This list is probably not comprehensive but is a start. These projects will need to look at removing their CentOS 8 CI jobs (optionally replacing them with CentOS 8 Stream jobs): * devstack (victoria and older branches) * tripleo-validations * tripleo-upgrade * openstack-ansible * rally * aodh * cinderlib * kolla-ansible * openstack-chef * sahara * tenks * validations-common * validations-lib One thing to keep in mind is that stable branches may also be affected. We'd like to do this cleanup as gracefully as possible, but reality is that some projects are unlikely to completely remove their use of CentOS 8. I think that we can give it until the end of January before we force merge updates to remove the nodeset and label from our configs. At that point any Zuul configuration still using CentOS 8 will enter an error state and correcting it will be necessary to make updates to those Zuul configs. [0] https://lists.opendev.org/pipermail/service-announce/2021-December/000029.h… [1] https://review.opendev.org/q/topic:%22remove-centos-8%22+status:open

7 8