November 2022 - openstack-discuss

[charms] Team Delegation proposal
by Chris MacNaughton 08 Feb '23

08 Feb '23

Hello All, <tl;dr> I would like to propose some new ACLs in Gerrit for the openstack-charms project: - openstack-core-charms - ceph-charms - network-charms - stable-maintenance </tl;dr> With an increasing focus split among the openstack-charmers team, I'm observing that people are focused on more specific subsets of the charms, and would like to propose that new ACLs are created to allow us to recognize that officially. I've chosen the breakdown above as it aligns neatly with where the focus lines are at this point, letting developers work on their specific focus areas. This proposal would not reduce permissions for anybody who is currently a core on the openstack-charms project and, in fact, future subteam core members could aspire to full openstack-charmers core as well. Ideally, this approach will let us escalate developers to "core" developers for the subteam(s) where they have demonstrated the expertise we expect in a core-charmer. It also allows a more gradual escalation to being a core in the openstack-charms project, making it a progression rather than a single destination. As a related addition, I'm appending to this proposal the creation of a stable-maintenance ACL which would allow members to manage backports without a full core-charmer grant. --- Chris MacNaughton

5 7

[cinder][drivers] third-party CI for os-brick changes
by Brian Rosmaita 04 Jan '23

04 Jan '23

To all third-party CI maintainers, As you are aware, cinder third-party CI systems are required to run on all cinder changes. However, the os-brick library used in cinder CI testing is the latest appropriate *released* version of os-brick. Thus, it is possible for changes to be happening in os-brick development that might impact the functionality of your driver. If you aren't testing os-brick changes, you won't find out about these until *after* the next os-brick release, which is bad news all around. Therefore, at last week's cinder midcycle [0], the cinder project team agreed to require that cinder third-party CI systems run on all os-brick changes in addition to all cinder changes. This is a nice-to-have for the current (Zed) development cycle, but will be required in order for a driver to be considered 'supported' in the 2023.1 (Antelope) release [1]. If you have comments or concerns about this policy, please reply on the list to this email or put an item on the agenda [2] for the cinder weekly meeting. [0] https://etherpad.opendev.org/p/cinder-zed-midcycles [1] https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers#What_changes… [2] https://etherpad.opendev.org/p/cinder-zed-meetings

2 1

Glance api deployed only on a single controller on multi-controller deployment [kolla]
by A Monster 30 Dec '22

30 Dec '22

I've deployed openstack xena using kolla ansible on a centos 8 stream cluster, using two controller nodes, however I found out after the deployment that glance api is not available in one node, I tried redeploying but I got the same behavior, although the deployment finished without displaying any error. Thank you. Regards

4 4

The CFP for the OpenInfra Summit 2023 is open!
by Erin Disney 25 Dec '22

25 Dec '22

Hi Everyone! The CFP for the 2023 OpenInfra Summit (June 13-15, 2023) is NOW LIVE [1]! Check out the full list of tracks and submit a talk on your topic of expertise [2]. The CFP closes January 10, 2023, at 11:59 p.m. PT We are also now accepting submissions for Forum sessions [3]! What should you submit to the forum vs. the traditional CFP? For the Forum, submit discussion-oriented sessions, including challenges around different software components, working group progress or best practices to tackle common issues. Looking for other resources? Registration [4], sponsorships [5], travel support [6] and visa requests [7] are also all open! Find all the information on the OpenInfra Summit 2023 in one place [8]! Cheers, Erin [1] https://cfp.openinfra.dev/app/vancouver-2023/19/presentations <https://cfp.openinfra.dev/app/vancouver-2023/19/presentationshttps://cfp.op…> [2] https://openinfra.dev/summit/vancouver-2023/summit-tracks/ <https://openinfra.dev/summit/vancouver-2023/summit-tracks/> [3] https://cfp.openinfra.dev/app/vancouver-2023/20/ <https://cfp.openinfra.dev/app/vancouver-2023/20/> [4] http://openinfra.dev/summit/registration <http://openinfra.dev/summit/registration> [5] http://openinfra.dev/summit/vancouver-2023/summit-sponsor/ <http://openinfra.dev/summit/vancouver-2023/summit-sponsor/> [6] https://openinfrafoundation.formstack.com/forms/openinfra_tsp <https://openinfrafoundation.formstack.com/forms/openinfra_tsp> [7] https://openinfrafoundation.formstack.com/forms/visa_yvrsummit2023 <https://openinfrafoundation.formstack.com/forms/visa_yvrsummit2023> [8] https://openinfra.dev/summit/vancouver-2023 <https://openinfra.dev/summit/vancouver-2023>

2 1

[all][TC] Bare rechecks stats week of 25.07
by Slawek Kaplonski 16 Dec '22

16 Dec '22

Hi, Here are fresh data about bare rechecks. +--------------------+---------------+--------------+-------------------+ | Team | Bare rechecks | All Rechecks | Bare rechecks [%] | +--------------------+---------------+--------------+-------------------+ | requirements | 2 | 2 | 100.0 | | keystone | 1 | 1 | 100.0 | | OpenStackSDK | 3 | 3 | 100.0 | | tacker | 3 | 3 | 100.0 | | freezer | 1 | 1 | 100.0 | | rally | 1 | 1 | 100.0 | | OpenStack-Helm | 14 | 15 | 93.33 | | cinder | 6 | 7 | 85.71 | | kolla | 20 | 25 | 80.0 | | neutron | 4 | 5 | 80.0 | | Puppet OpenStack | 10 | 13 | 76.92 | | OpenStack Charms | 3 | 6 | 50.0 | | nova | 11 | 22 | 50.0 | | tripleo | 8 | 19 | 42.11 | | ironic | 1 | 3 | 33.33 | | Quality Assurance | 1 | 3 | 33.33 | | octavia | 0 | 1 | 0.0 | | OpenStackAnsible | 0 | 1 | 0.0 | | designate | 0 | 1 | 0.0 | | Release Management | 0 | 1 | 0.0 | | horizon | 0 | 1 | 0.0 | +--------------------+---------------+--------------+-------------------+ Those data should be more accurate as my script now counts only comments from last 7 days, not all comments from patches updated in last 7 days. Reminder: "bare rechecks" are recheck comments without any reason given. If You need to do recheck for patch due to failed job(s), please first check such failed job and try to identify what was the issue there. Maybe there is already opened bug for that or maybe You can open new one and add it as explanation in the recheck comment. Or maybe it was some infra issue, in such case short explanation in the comment would also be enough. -- Slawek Kaplonski Principal Software Engineer Red Hat

6 10

[manila][release] Proposing to EOL Stein
by Carlos Silva 14 Dec '22

14 Dec '22

Hello! Recently in a weekly meeting we chatted about EOLing stable/stein and all the attendants were found to be in favor of this [0]. As the procedures go [1], we need to make it formal through a post in this mailing list, and see if there are objections. In case of concerns or objections, please reach out through email or the #openstack-manila IRC channel. This will impact all branched manila repositories (manila, python-manilaclient and manila-ui). If there aren't objections or strong concerns, I will be proposing the patches to EOL stable/stein within one week. [0] https://meetings.opendev.org/meetings/manila/2022/manila.2022-11-03-15.00.l… [1] https://docs.openstack.org/project-team-guide/stable-branches.html#end-of-l… Thanks, carloss

1 1

[cinder] volume_attachement entries are not getting deleted from DB
by Hemant Sonawane 13 Dec '22

13 Dec '22

Hello I am using wallaby release openstack and having issues with cinder volumes as once I try to delete, resize or unshelve the shelved vms the volume_attachement entries do not get deleted in cinder db and therefore the above mentioned operations fail every time. I have to delete these volume_attachement entries manually then it works. Is there any way to fix this issue ? nova-compute logs: cinderclient.exceptions.ClientException: Unable to update attachment.(Invalid volume: duplicate connectors detected on volume Help will be really appreciated Thanks ! -- Thanks and Regards, Hemant Sonawane

3 6

[neutron][devstack][qa] Dropping lib/neutron module
by Slawek Kaplonski 12 Dec '22

12 Dec '22

Hi, As You maybe know (or not as this was very long time ago) there are 2 modules to deploy Neutron in devstack: * old one called lib/neutron-legacy * new one called lib/neutron The problem is that new module lib/neutron was really never finished and used widely and still everyone is using (and should use) old one lib/neutron-legacy. We discussed that few times during PTGs and we finally decided to drop "new" module lib/neutron and have then rename old "lib/neutron-legacy" to be "lib/neutron" again. Decision was made because old module works fine and do its job, and as there is nobody who would like to finish really new module. Also having 2 modules from which "legacy" one is the only one which really works can be confusing and we want to avoid that confusion. So I proposed patches [1] and [2] to drop this unfinished module. I also proposed DNM patches for Neutron [3] and Tempest [4] to test that all jobs will work fine. But if You are maybe relaying on the Neutron modules from Devstack, please propose some test patch in Your project too and check if everything works fine for You. In patch [2] I didn't really removed "lib/neutron-legacy" yet because there are some projects which are sourcing that file in their devstack module. As [1] and [2] will be merged I will be proposing patches to change that for those projects but any help with that is welcome :) [1] https://review.opendev.org/c/openstack/devstack/+/865014 [2] https://review.opendev.org/c/openstack/devstack/+/865015 [3] https://review.opendev.org/c/openstack/neutron/+/865822 [4] https://review.opendev.org/c/openstack/tempest/+/865821 -- Slawek Kaplonski Principal Software Engineer Red Hat

2 1

[ironic][release] Bugfix branch status and cleanup w/r/t zuul-config-errors
by Jay Faulkner 07 Dec '22

07 Dec '22

Hey all, I've been looking into the various zuul config errors showing up for Ironic-program branches. Almost all of our old bugfix branches are in the list. Additionally, not properly retiring the bugfix branches leads to an ever-growing list of branches which makes it a lot more difficult, for contributors and operators alike, to tell which ones are currently supported. I've put together a document describing the situation as it is now, and my proposal: https://etherpad.opendev.org/p/IronicBugfixBranchCleanup Essentially, I think we need to: - identify bugfix branches to cleanup (I've done this in the above etherpad, but some of the ) - clean them up (the next step) - update Ironic policy to set a regular cadence for when to retire bugfix branches, and encode the process for doing so This means there are two overall questions to answer in this email: 1) Mechanically, what's the process for doing this? I don't believe the existing release tooling will be useful for this, but I'm not 100% sure. I've pulled (in the above etherpad and a local spreadsheet) the last SHA for each branch; so we should be able to EOL these branches similarly to how we EOL stable branches; except manually instead of with tooling. Who is going to do this work? (I'd prefer releases team continue to hold the keys to do this; but I understand if you don't want to take on this manual work). 2) What's the pattern for Ironic to adopt regarding these branches? We just need to write down the expected lifecycle and enforce it -- so we prevent being this deep into "branch debt" in the future. What do folks think? - Jay Faulkner

4 6

[heat][release] Proposing to EOL Rocky and Stein
by Brendan Shephard 06 Dec '22

06 Dec '22

Hi, We were discussing some of the older branches we have and thought it was about time we start moving some of them to EOL. Initially, I would like to move Rocky and Stein to EOL and have done so here: https://review.opendev.org/c/openstack/releases/+/866135 We would also like to move Train to EOL as well, pending a few changes being merged. I wanted to reach out and ensure there is no objections here to any of these branches being EOL’d. Feel free to voice any concerns, otherwise I will move forward with that next week. Cheers, Brendan Shephard Senior Software Engineer Red Hat Australia

2 1