September 2022 - openstack-discuss

[neutron] bug deputy report (week of Sep 5)
by Akihiro Motoki 13 Sep '22

13 Sep '22

Hi, I was a bug deputy last week. It was a quiet week and only two new bugs are unassigned. ## Unassigned * https://bugs.launchpad.net/neutron/+bug/1988793 OVN as a Provider Driver for Octavia in ovn-octavia-provider This is a request to add a limitation corresponding to bug 1901936 (manual failure over is not supported) to the document. Hopefully ovn-octavia-driver folks can update the limitations section in the doc. * Neutron 20.2 Unknown Chassis Issue https://bugs.launchpad.net/neutron/+bug/1989155 ralonso suggested to file a bug on this to OVN upstream. It seems an issue in OVN core and perhaps we can mark it as invalid in neutron. ## In Progress * https://bugs.launchpad.net/neutron/+bug/1989391 [OVN] Allowed Address Pairs which is netmask doesn't work Thanks, Akihiro Motoki (amotoki)

1 0

Openstack.io is down
by Elvira Garcia Ruiz 13 Sep '22

13 Sep '22

Hi everyone! I noticed that stackalytics.io has been down for several days now. As far as I know this was widely used by the community, although it is not part of OpenInfra as a project. I'm not sure who was maintaining this, but I just wanted to make them aware of the problem, and also thank them for keeping it up and running. Kind regards! Elvira García (irc:elvira)

5 5

[openstack yova][nova-spiceproxy] Spice proxy behind SSL termination: protocol mismatch error in horizon web UI
by 박경원 13 Sep '22

13 Sep '22

2 1

[tripleo] puppetlabs-apache: soon a just a bad memory?
by Cédric Jeanneret 13 Sep '22

13 Sep '22

Hello Community! TLDR; puppetlabs-apache broke us so many times, I'm proposing a way to get rid of it, using plain ansible. Some work is needed, but it's "easy", and will allow us to keep a hand on the whole configuration code. Longer version: You probably saw mails about issues with puppetlabs-apache releases breaking the CI (and, by extension, TripleO). Over and over and over again. Well, good news: this may be just a bad memory - though it will require some work :). I've been working on a couple of ansible roles[1] in order to just get the needed pieces we really need in TripleO: file generation. Once we get those 2 roles in, we'll be able to switch, service by service, away from puppet management for apache/httpd. There's already an on-going example[2] with ironic. Of course, as you can see, there's some work to do, even on the puppet side. But it's not really complicated, and can be done quickly. I'll do my best to move things, but be prepared to get pings from time to time if help is needed. I can't do all by myself, can I? ;) And if anyone wants to jump in and work on the transition, please do, and don't hesitate to reach to me, either by mail, or on #tripleo - I go there as Tengu. Cheers, C. [1] https://review.opendev.org/c/openstack/tripleo-ansible/+/853481 [2] https://review.opendev.org/q/topic:standalone%252Fapache -- Cédric Jeanneret (He/Him/His) Sr. Software Engineer - OpenStack Platform Deployment Framework TC Red Hat EMEA https://www.redhat.com/

1 0

[tripleo] Switching to nftables - it's coming soon!
by Cédric Jeanneret 13 Sep '22

13 Sep '22

Hello there, TLDR; we're about to switch to nftables[1], there are some changes described in the up-to-date doc. Reason is: faster, more modern interface, close to no possibility to get locked out of the system. Also, once it's switched, please use `nft list ruleset' instead of `iptables -L'. [1] https://review.opendev.org/c/openstack/tripleo-heat-templates/+/852808 Longer version: I've been working a good amount of time in order to get rid of the current tripleo_iptables custom action. On of the reasons here was the fact we could get locked out the overcloud if, for any reason, a network reset happens in ansible during the application of the rules. For the records, tripleo_iptables is calling the native "iptables" module from ansible, just doing a batching of the ruleset in an attempt to apply everything faster. It has some weird things, such as reversing the rule order before applying them using the "insert" action, meaning it will lock everything first, then open one by one the accesses. Knowing "ssh" is like 003 rule, you can imagine how things can go wrong. So, I took the opportunity to make some changes. While doing so, I saw `iptables' was just a compatibility wrapper for nftables - basically, `iptables' is a symlink to `iptables-nft', so I also took the opportunity to bypass it, and go straight for `nft'. Doing so, I created a new tripleo_nftables role in tripleo-ansible project; it's "just" creating files based on templates, then validates the whole lot of files, and applies all the rules in one single transaction. Compared to tripleo_iptables, it's really more robust, while being faster, and less prone to lock out and other unwanted things. The current state is: we're close, really close to switch things up. We're missing 2 patches in the CI to make the infra properly supported, and then, there's "the" switch itself. What will change: almost nothing: the way we create rules in tripleo-heat-templates and the different parameters therein doesn't change at all; the thing that will really change is the way to list the rules: instead of calling `iptables -vnL' or the like, you'll need to call `nft list ruleset'. Now, in order to make things easier, the doc is already up-to-date: https://docs.openstack.org/project-deploy-guide/tripleo-docs/latest/feature… As you will see, there will be some differences in the actual layout: all of the tripleo rules will be in dedicated chains, prefixed by TRIPLEO_ - for instance, TRIPLEO_INPUT, TRIPLEO_OUTPUT, TRIPLEO_FORWARD, and so on. This allows to get a cleaner layout, cleaner way to filter the output and, really important thing, to ensure we're cleaning dangling rules - the TRIPLEO_* chains will be flushed before the ruleset are added. All in one single transaction. Some more information/content: tripleo_nftables role: https://opendev.org/openstack/tripleo-ansible/src/branch/master/tripleo_ans… Doc: https://docs.openstack.org/project-deploy-guide/tripleo-docs/latest/feature… Debug files available in the CI: log of dropped packets: https://logserver.rdoproject.org/54/31954/87/check/periodic-tripleo-ci-cent… nftables configuration dump: https://logserver.rdoproject.org/54/31954/87/check/periodic-tripleo-ci-cent… nftables configuration: https://logserver.rdoproject.org/54/31954/87/check/periodic-tripleo-ci-cent… All of that can help understanding the potential issues you may encounter. As a side note, we've been testing the whole thing for about a month now, correcting issues, updating the doc and making sure at least all of the current CI jobs (yes: ALL) are green without any weird behavior. A doc has been created in order to list the current state, with what we've seen, what we've done: https://hackmd.io/F0W2gYw_SiaiWkowjFU9cw?view#NFTABLES-testing-results Brace yourself, the change is coming :). But it should be transparent ;). -- Cédric Jeanneret (He/Him/His) Sr. Software Engineer - OpenStack Platform Deployment Framework TC Red Hat EMEA https://www.redhat.com/

1 0

[publiccloud-sig] Bi-weekly meeting reminder
by Tobias Rydberg 13 Sep '22

13 Sep '22

Hi all, Tomorrow we will have our bi-weekly meeting at 0800 UTC in #openstack-operators. Notes from previous meeting can be found here [0]. Please go in prior to the meeting and vote for for the naming conventions suggested, which you believe are the most important or if you think some of them should not be considered at all. Hope to chat with you tomorrow! [0] https://etherpad.opendev.org/p/publiccloud-sig-meeting BR, Tobias Rydberg

1 0

[ptl][tc][election][adjutant][barbican][OpenStackSDK][OpenStack_Charms][sahara][swift][venus] Leaderless project for 2023.1 cycle
by Ghanshyam Mann 13 Sep '22

13 Sep '22

Hello, As you know, 2023.1 cycle election nomination is ended and we end up with 11 leaderless projects. List is in the etherpad: https://etherpad.opendev.org/p/2023.1-leaderless Out of 11, we have found 4 projects leaders but 7 (in the subject list) projects still need some leaders to volunteer: 1. Adjutant 2. Barbican 3. OpenStackSDK 3. OpenStack_Charms 4. Sahara 5. Swift 6. Venus Please reply here or ping us in #openstack-tc channel if you would like to lead these projects. -gmann

2 4

[cinder][stable] cinder-stable-core additions
by Rajat Dhasmana 13 Sep '22

13 Sep '22

Hi All, After discussing with the current members of the cinder stable core team, I've decided to add the following members to the cinder stable core team. 1) Walter Boring - (Currently cinder core) 2) Sofia Enriquez - (Currently cinder core) Sofia and Walt have been long term contributors in the Cinder project and I'm happy to have them as part of the stable core team. I will proceed with making changes to the stable core team[1]. [1] https://review.opendev.org/admin/groups/1b3ca2faf07b15efff426901a387eb7c914… Thanks and Regards Rajat Dhasmana

1 0

[all][elections][ptl][tc] Conbined PTL/TC antelope cycle Election Voting Kickoff
by Ian Y. Choi 13 Sep '22

13 Sep '22

Polls for PTL and TC elections are now open and will remain open for you to cast your vote until Sep 19, 2022 23:45 UTC. We are selecting 4 TC members, and are having PTL elections for Ironic. Please rank all candidates in your order of preference. You are eligible to vote in the TC election if you are a Foundation individual member[0] that also has committed to any official project team's deliverable repositories[1] over the Sep 17, 2021 00:00 UTC - Sep 07, 2022 00:00 UTC timeframe (Yoga to Zed) or if you are in the list of extra-atcs[2] for any official project team. You are eligible to vote in a PTL election if you are a Foundation individual member[0] and had a commit in one of that team's deliverable repositories[1] over the Sep 17, 2021 00:00 UTC - Sep 07, 2022 00:00 UTC timeframe (Yoga to Zed) or if you are in that team's list of extra-atcs[2]. If you are eligible to vote in an election, you should find your email with a link to the Condorcet page to cast your vote in the inbox of your Gerrit preferred email[3]. What to do if you don't see the email and have a commit in at least one of the projects having an election: * check the trash or spam folders of your gerrit Preferred Email address, in case it went into trash or spam * wait a bit and check again, in case your email server is a bit slow * find the sha of at least one commit from the project's deliverable repos[0] and email the election officials [4] * requires opt-in to CIVS polling to receive email communications from the voting system [5]. If we can confirm that you are entitled to vote, we will add you to the voters list for the appropriate election. Our democratic process is important to the health of OpenStack, please exercise your right to vote! Candidate statements/platforms can be found linked to Candidate names on this page: https://governance.openstack.org/election/ Happy voting, /Ian, as one of OpenStack Election Officials [0] https://www.openstack.org/community/members/ [1] The list of the repositories eligible for electoral status: https://opendev.org/openstack/governance/src/tag/oct-2022-elections/referen… [2] Look for the extra-atcs element in [1] [3] Sign into review.openstack.org: Go to Settings > Contact Information. Look at the email listed as your preferred email. That is where the ballot has been sent. [4] https://governance.openstack.org/election/#election-officials [5] https://lists.openstack.org/pipermail/openstack-discuss/2022-September/0304…

1 0

[baremetal-sig][ironic] Future of baremetal-sig
by Jay Faulkner 13 Sep '22

13 Sep '22

Stackers, An item came up in the Ironic meeting today regarding the future of the baremetal sig. Essentially, Arne was doing great work sourcing talks for it, but now he's going to be unable to continue hosting it and proactively sourcing talks. (A seriously big thanks is owed to Arne for doing a great job on this!) This led us to wonder if BM SIG in its current form remains sustainable. Some options we can consider include: - Keep the BM SIG as-is, cancel it months where there's not a talk available. - Change the BM SIG meetings to more of a meetup style for operators to talk about Ironic - Something else entirely we haven't thought about yet. What do you all think? - Jay Faulkner

1 0