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

[cinder] festival of XS reviews 18 March 2022
by Brian Rosmaita 16 Mar '22

16 Mar '22

Hello Argonauts, Just in case there's anyone out there who has not used the handy ICS file [0] to have this event on their personal calendars: The most recent edition of the Cinder Festival of XS Reviews will be held on this coming Friday (18 March). who: Everyone! what: The Cinder Festival of XS Reviews when: Friday 18 March 2022 from 1400-1600 UTC where: https://meetpad.opendev.org/cinder-festival-of-reviews etherpad: https://etherpad.opendev.org/p/cinder-festival-of-reviews See you there! brian [0] http://eavesdrop.openstack.org/calendars/cinder-festival-of-reviews.ics

1 0

[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