November 2022 - openstack-discuss

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 26 Dec '22

26 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 17 Dec '22

17 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 07 Dec '22

07 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

[nova][placement][tempest] Hold your rechecks
by Sylvain Bauza 05 Dec '22

05 Dec '22

Sorry folks, that's kind of an email I hate writing but let's be honest : our gate is busted. Until we figure out a correct path for resolution, I hereby ask you to *NOT* recheck in order to not spill our precious CI resources for tests that are certain to fail. Long story story, there are currently two problems : #1 https://launchpad.net/bugs/1940425 nova-ovs-hybrid-plug and nova-next jobs 100% fail due to a port remaining in down state. #2 https://bugs.launchpad.net/nova/+bug/1960346 nova-lvm job 100% fails due to a volume detach failure probably due to QEMU #1 is currently investigated by the Neutron team meanwhile a patch [1] has been proposed against Zuul to skip the failing tests. Unfortunately, this patch [1] is unable to merge due to #2. #2 has a Tempest patch that's being worked on [2] but the current state of this patch is WIP. We somehow need to have an agreement on the way forward during this afternoon (UTC) to identify whether we can reasonably progress on [2] or skip the failing tests on nova-lvm. Again, sorry about the bad news and I'll keep you informed. -Sylvain [1] https://review.opendev.org/c/openstack/nova/+/865658/ [2] https://review.opendev.org/c/openstack/tempest/+/842240

2 5

[Magnum] ls /etc/cni/net.d/ is emty
by Nguyễn Hữu Khôi 01 Dec '22

01 Dec '22

Hello guys. I use Magnum on Xena and I custom k8s cluster by labels. But My cluster is not ready and there is nothing in /etc/cni/net.d/ and my cluster said: container runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:Network plugin returns error: cni plugin not initialized And this is my labels kube_tag=v1.21.8-rancher1,container_runtime=containerd,containerd_version=1.6.10,containerd_tarball_sha256=507f47716d7b932e58aa1dc7e2b3f2b8779ee9a2988aa46ad58e09e2e47063d8,calico_tag=v3.21.2,hyperkube_prefix= docker.io/rancher/ Note: I use Fedora Core OS 31 for images. Thank you. Nguyen Huu Khoi

2 3