September 2022 - openstack-discuss

[vitrage] RCA not showing on dashboard
by Carlos Rodríguez 13 Sep '22

13 Sep '22

Hi, I hope find very well, We are using vitrage-dashboard, but right we are presenting problems displaying the RCA alarm graph. [image: vitrageerror.png] When clicking RCA button in any alarm, the graph is not displayed and the following error is shown in inspector: Error: layers[node.rank] is undefined Downgrading to vitrage-dashboard stable/train seems to solve the issue. For the latest releases, the issue is solved when the following commit is reverted: d181623f22 Replace embedded static files with XStatic-* It seems that there is some problem with the XStatic libraries. Tested in Chrome, Firefox, Edge. Openstack release: Victoria Are you working to solve this problem? Or do you have any solution to display the graph. Thanks for your time, kind regards.

1 0

Outreachy 2022 - 2023?
by Sofia Enriquez 13 Sep '22

13 Sep '22

Hello, I'd like to propose myself as a mentor for this Outreachy round. However, I haven't seen any email on the mailing list announcing that OpenStack is joining this round. Please let me know if Openstack is going to sponsor the next rounds. Thanks in advance, Best, 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>

3 3

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

12 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 12 Sep '22

12 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 12 Sep '22

12 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