March 2022 - openstack-discuss - lists.openstack.org

[kolla] Using variable in ceph confs
by Imran Hussain 16 Mar '22

16 Mar '22

Hi All, I'm storing my kolla conf in git and I want to avoid committing secrets. As per the subject I'm using an external ceph. I've created a patchset for this to be possible https://review.opendev.org/c/openstack/kolla-ansible/+/824566 Jens replied to it pretty fast but beyond saying 'I don't understand why you would want to do this' (paraphrased) gave no feedback. I recently got some feedback from Michal after asking on IRC about it which was very helpful. But this doesn't seem to be going anywhere, any advice on next steps? Even if the feedback is 'no we don't want this' anything would be nice. Thanks, Imran

1 0

[dev] [trove] Bug fixed from master to stable branch and release?
by Hirotaka Wakabayashi 16 Mar '22

16 Mar '22

Hello, I am a Trove contributor. I proposed a cherry-pick and lxkong kindly merged it yesterday! Could someone release the new version as 13.0.1? Because I believe this bug is significant for users for some reasons. 1. I hit this bug :P 2. One relevant Issue from IRC https://meetings.opendev.org/irclogs/%23openstack-trove/%23openstack-trove.… 3. One relevant issue from https://storyboard.openstack.org/#!/story/2006996 This patch is cherry-picked from master branch and I think this patch has no risk of regression. Thanks in advance, Hirotaka

1 0

[PTG] April 2022 Teams List
by Kendall Nelson 16 Mar '22

16 Mar '22

Hello Everyone! The April 2022 Project Teams List is official! Ansible OpenStack modules Barbican Blazar Cinder CloudKitty Cyborg Designate Diversity & Inclusion WG First Contact SIG Glance Horizon Interop Ironic Keystone Kolla Kuryr Large Scale SIG Manila Neutron Nova/Placement Octavia OpenInfra Edge Computing Group OpenStack Charms OpenStack Technical Committee OpenStack-Ansible OpenStack-Helm QA Release Management SDK Security SIG StarlingX Swift Tacker TripleO If your team was planning to meet and isn’t in this list, please contact ptg(a)openinfra.dev IMMEDIATELY. Otherwise, please don't forget to register[1] because that's how you'll receive event details, passwords, and other relevant information about the PTG. Please let us know if you have any questions! Thanks! -Kendall (diablo_rojo) [1] PTG Registration: https://openinfra-ptg.eventbrite.com

2 2

[openstack][keystone] Stepping down from core
by Gage Hugo 15 Mar '22

15 Mar '22

After some consideration and my focus shifting to other priorities, I cannot reliably devote enough time to keystone so I'll be stepping down from keystone core. I greatly appreciate the experiences I had to learn and grow thanks to everyone's help. Thanks to you all and I'm grateful for the opportunities I've had with the project and openstack as a whole. Hopefully we will get to collaborate again more in the future. Gage Hugo

2 2

[tc][release] Removing TC tags framework - next steps for release notes
by Radosław Piliszek 15 Mar '22

15 Mar '22

Hello Release Team, As you might have heard, the TC is removing the TC tags framework. [1] The first step has already been proposed and is being voted on. [2] The removal of certain parts seems to be affecting the release team tooling, especially with the usage of the stable:follows-policy tag to show a relevant banner. [3] The proposed change purposely avoids breaking the releases repo and awaits a "part 2" which cleans up everything TC-tags-framework-related. Thus, I am asking for your help to remove this dependency on the tags framework. I understand there might be several approaches to this and need your assistance to continue. The simplest approach is to drop the relevant code - assuming it is not actively used for release process purposes. Obviously, for anything else I need your input on what the options are. It is also possible that you would prefer to port this tag to your internal metadata. I am open to ideas and will help enact the changes. [1] http://lists.openstack.org/pipermail/openstack-discuss/2021-October/025554.… [2] https://review.opendev.org/c/openstack/governance/+/822900 [3] https://opendev.org/openstack/releases/src/commit/768a12e233c23999db18c807c… Kind regards, -yoctozepto

3 4

[release] Independent release jobs are still using old release job templates
by Stephen Finucane 15 Mar '22

15 Mar '22

tl;dr: How do we get projects using the independent release process to use the openstack-python3 zuul job template corresponding to the latest release? I've noticed a couple of patches like [1] popping up for oslo-affiliated projects. These projects are currently using the python3 zuul job templates corresponding to an older release (e.g. Wallaby) and the author is correctly updating them to use the most recent release. These initially caught me off-guard since I'm used to seeing a bot propose these changes but I've realized that all affected projects are using the "independent" release process and therefore don't receive a new stable branch nor related bot-proposed commits. This leaves us in a bit of a pickle though. There are a lot of projects using this release process, and there's effectively zero chance that someone is going to remember to bump the jobs every single release. While some could argue that this is "working as designed", it seems important to me that we would be testing these projects against the supported runtimes for the release currently under development. As such, how should we try to address this? One option I see is to add a new generic 'openstack-python3-jobs' template which would always duplicate the jobs used for the current release. I've proposed that here [2]. There are some pros and cons to this approach: * PRO: Minimal effort from everyone. * CON: The HEAD of master for each project could be broken and we'd never know until some change was proposed to master (note: this is effectively the status quo right now, so it's not a big break) * CON: If those independent projects had an alternative to stable branches (i.e. semver branches), those would eventually break as the runtimes kept changing. The other option is to extend the openstack bot to propose release bump patches against these independent projects. This has the inverse pro/con balance: * PRO: We get a regular "check-up" on the health of the project whenever these patches are proposed. * PRO: Long-lived stable branches should stay working * CON: Lots of busy work for reviewers. What are everyone's thoughts? I'm in favour of the first approach (generic 'openstack-python3-jobs' template) but the bot enhancement would also wfm. If we go with the first approach, we'd probably want to script something to "fix" all the existing independent projects rather than attempt to find and fix them manually. Cheers, Stephen PS: Apologies if this has been discussed previously. I clearly missed that discussion. [1] https://review.opendev.org/c/openstack/os-api-ref/+/831560 [2] https://review.opendev.org/c/openstack/openstack-zuul-jobs/+/833286

4 7

[infra] gerrit is:mergeable predicate
by Brian Rosmaita 15 Mar '22

15 Mar '22

Hello Infra team, In Gerrit 3.4, the is:mergeable predicate is disabled by default [0]. It was kind of handy to be able to screen out patches that are in merge conflict when looking for reviews. Is there an alternative way of doing this, or would you be averse to restoring the previous behavior? (I promise not to complain about gerrit performance.) cheers, brian [0] https://www.gerritcodereview.com/3.4.html#ismergeable-predicate-is-disabled…

2 3

[neutron] bug deputy report (Mar 7 - 13)
by Akihiro Motoki 15 Mar '22

15 Mar '22

Hi, Here is a bug deputy report last week. It was a quiet week too. = Needs attention - https://bugs.launchpad.net/neutron/+bug/1964339 [OVN Octavia Provider] OVN provider tests using too old version of OVN it looks like local.conf in ovn-octavia-provider-functional-release is not configured properly, so the bug reported here looks valid. Hopefully ovn-octavia-provider folks can look into it. = Gate Failures - https://bugs.launchpad.net/neutron/+bug/1963899 Rebuild server - notification about port UP isn't sent to nova properly Confirmed, Unassigned - https://bugs.launchpad.net/neutron/+bug/1964313 Functional tests fails due to missing namespace Confirmed, Unassigned = Assigned - https://bugs.launchpad.net/neutron/+bug/1964817 [ovn-octavia-provider] Deleted members remain in ERROR status = RFE - https://bugs.launchpad.net/neutron/+bug/1964765 DHCP agent scheduler filtering ignored when agent service restarted - https://bugs.launchpad.net/neutron/+bug/1964342 [QoS][OvS] implement QoS bandwidth limitation by leveraging ovs meter Thanks, Akihiro Motoki (amotoki)

1 0

Re: [release] Independent release jobs are still using old release job templates
by Stephen Finucane 15 Mar '22

15 Mar '22

On Fri, 2022-03-11 at 17:13 +0100, Előd Illés wrote: > Thanks for bringing this up Stephen! I am not aware of such discussions, > though i might missed it only. > > So this is about projects with 'independent release model' and their CI > jobs. I think it's a valid question and we should solve this somehow. > > I could also imagine a new task in our release process / schedule, when the > release team generates the new patches via some new scripts (which is > somewhat identical to your second option). This has the risk though that these > kind of patches just linger around without anyone reviewing / fixing / merging them > (similarly like the .gitreview and TOX_CONSTRAINTS_FILE patches, which > should be merged as soon as possible, but in lots of projects they just remain > there open forever, causing errors time to time). Considering this, maybe the 2nd > option is better but what you wrote as CON regarding special (ie. semver) > stable branches could be really problematic (I don't know actually, so > we need to ask for opinions from those projects that have such stable branches > in their projects with independent release model). I've thought about this more, and I don't think the issue with the special stable branches is actually a big issue. Firstly, I've no evidence that such things even exist so it's likely a purely theoretical issue at this point. However, assuming these branches _do_ exist, they would have to be created manually. There's no reason that the '.zuul.yaml' file couldn't be modified after this was done to use the job template from the current release (i.e. 'openstack-python3-zed-jobs'), ensuring things would age gracefully. If we have "how to request manual stable branch creation" docs somewhere, then we could simply note this there. I think the unversioned job is definitely the way to go now. I just need another approver for [1] to move forward with it. Stephen [1] https://review.opendev.org/c/openstack/openstack-zuul-jobs/+/833286 > > Thanks, > > Előd > > On 2022. 03. 11. 13:26, Stephen Finucane wrote: > > tl;dr: How do we get projects using the independent release process to use the > > openstack-python3 zuul job template corresponding to the latest release? I've > > noticed a couple of patches like [1] popping up for oslo-affiliated projects. > > These projects are currently using the python3 zuul job templates corresponding > > to an older release (e.g. Wallaby) and the author is correctly updating them to > > use the most recent release. These initially caught me off-guard since I'm used > > to seeing a bot propose these changes but I've realized that all affected > > projects are using the "independent" release process and therefore don't receive > > a new stable branch nor related bot-proposed commits. This leaves us in a bit of > > a pickle though. There are a lot of projects using this release process, and > > there's effectively zero chance that someone is going to remember to bump the > > jobs every single release. > > > > While some could argue that this is "working as designed", it seems important to > > me that we would be testing these projects against the supported runtimes for > > the release currently under development. As such, how should we try to address > > this? One option I see is to add a new generic 'openstack-python3-jobs' template > > which would always duplicate the jobs used for the current release. I've > > proposed that here [2]. There are some pros and cons to this approach: > > > > * PRO: Minimal effort from everyone. > > * CON: The HEAD of master for each project could be broken and we'd never know > > until some change was proposed to master (note: this is effectively the > > status quo right now, so it's not a big break) > > * CON: If those independent projects had an alternative to stable branches > > (i.e. semver branches), those would eventually break as the runtimes kept > > changing. > > > > The other option is to extend the openstack bot to propose release bump patches > > against these independent projects. This has the inverse pro/con balance: > > > > * PRO: We get a regular "check-up" on the health of the project whenever these > > patches are proposed. > > * PRO: Long-lived stable branches should stay working > > * CON: Lots of busy work for reviewers. > > > > What are everyone's thoughts? I'm in favour of the first approach (generic > > 'openstack-python3-jobs' template) but the bot enhancement would also wfm. If we > > go with the first approach, we'd probably want to script something to "fix" all > > the existing independent projects rather than attempt to find and fix them > > manually. > > > > Cheers, > > Stephen > > > > PS: Apologies if this has been discussed previously. I clearly missed that > > discussion. > > > > [1] https://review.opendev.org/c/openstack/os-api-ref/+/831560 > > [2] https://review.opendev.org/c/openstack/openstack-zuul-jobs/+/833286 > > > >

1 0

[VICTORIA] Not working SNAT over VXLAN?
by Gaël THEROND 15 Mar '22

15 Mar '22

Hi everyone! I’m facing a weird situation on a tenant of one of our Openstack cluster based on Victoria. On this tenant, the network topology is as follow: One DMZ network (192.168.0.0/24) linked to our public network through a neutron router where there is a VM acting as a bastion/router for the MGMT network. One MGMT network (172.16.31.0/24) where all VMs are linked to. On the DMZ network, there is a linux Debian 11, let’s call it VM-A with a Floating IP from the public pool, this VM is both attached to the DMZ network (ens3 / 192.168.0.12) AND the MGMT network (ens4 / 172.16.31.23). All other VMs, let’s call them VM-X are exclusively attached to the MGMT network (ens4). I’ve setup VM-A with ip_forward kernel module and the following iptables rule: # iptables -t nat -A POSTROUTING -o ens3 -J SNAT —to-source 192.168.0.12 My VM-X are on their own setup with a default gateway via VM-A: # ip route add default via 172.31.16.23 The setup seems to be working as if I don’t put the iptables rule and the kernel forwarding I can’t see any packets on my DMZ interface (ens3) on VM-A from VM-X. Ok so now that you get the whole schema, let dive into the issue. So when all rules, modules and gateway are set, I can fully see my VM-X traffic (ICMP ping to a dns server) going from VM-X (ens4) to VM-A (ens4) then forwarded to VM-A (ens3) and finally going to our public IP targeted service. What’s not working however is the response not reaching back to VM-X. I’ve tcpdump the whole traffic from VM-X to VM-A on each point of the platfrom: from inside the VM-X nic, on the tap device, on the qbr bridge, on the qvb veth, on the qvo second side of the veth through the ovs bridges and vice-versa. However the response packets aren’t reaching back further than on the VM-A qvo veth. Once it exit the VM-A the traffic never reaches the VM-X. What’s really suspicious in here is that a direct ping from VM-X (172.16.31.54) to VM-A (172.16.31.23) is coming back correctly, so it looks like if ovs detected that the response on a SNAT case isn’t legit or something similar. Is anyone able to get such setup working? Here are few additional information: Host runs on CentOS 8.5 latest update. Our platform is a Openstack Victoria deployed using kolla-ansible. We are using a OVS based deployment. Our tunnels are VXLAN. All VMs have a fully open secgroup applied and all ports have it (I checked it twice and even on host iptables). If you ever need additional information feel free to let me know !

2 10