July 2022 - openstack-discuss - lists.openstack.org

[tc][qa][centos stream] CentOS-stream-9 testing stability and collaboration with CentOS-stream maintainers
by Ghanshyam Mann 09 Jul '22

09 Jul '22

Hello Everyone, As you know, CentOS-stream-9 is in Zed cycle testing runtime and we are facing some stability issues to make its testing voting (detach volume, qemu issues are some known ones). Currently, it is a non-voting job which is not good for the long term as non-voting job failures are mostly ignored. We called CentOS stream folks to discuss how to make it stable testing or a better way to improve the communication between both communities as well as coordinated debugging. Alan, Brian, and Aleksandra from the CentOS stream team joined the TC call on 7 July. With the CentOS stream model of having the latest packages version like libvirt etc it is good to test and capture the potential issues in advance but at the same time, there will more failure than other distros like ubuntu etc. Knowing the failure in the early stage is good but we have a few challenges to triage such failure. OpenStack or CentOS team alone might not be able to know the root cause of the issue at first glance, whether it is in OpenStack component or in CentOS stream. CentOS team has less experience in debugging devstack or tempest tests. And if such failures are more frequent (current case) then having it as a voting testing on every patch is another challenge for OpenStack smooth development cycle. We could not find any best solution to solve all these challenges but we all agree that we need some coordinated debugging. We need some of the initial level of failure debugging in OpenStack and pass the information to CentOS team for further debugging. That is one possible step forward and we will see how it goes. Basically doing the following : * If OpenStack members see failure in CentOS stream then do some initial level of debugging to know which OpenStack component is failing and collect some log information. * Report the bug with all those information at https://bugzilla.redhat.com/ * Contact CenntOS Stream team (you can address/ping Alan, Brian or Aleksandra ) via ** ML: https://lists.centos.org/mailman/listinfo/centos-devel ** IRC channel on Libera chat #centos-devel and #centos-stream Alan, Brian, Aleksandra, or any TC members feel free to add the things if I missed something. -gmann

1 0

[all][tc][gerrit] Ownership of *-stable-maint groups
by Stephen Finucane 09 Jul '22

09 Jul '22

tl;dr: Who should be able project-specific stable-maint groups on Gerrit: members of the projects-specific stable-maint group itself or members of stable- maint-core? A recent discussion on #openstack-sdks highlighted some discrepancies in the ownership of various project-specific "stable-maint" groups on Gerrit. As a reminder, any project that specifies "stable:follows-policy" is required to follow the stable branch policy (suprise!). This is documented rather well at [1]. We expect people who have the ability to merge patches to stable branches to understand and apply this policy. Initially the only people that could do this were peopled added to a central Gerrit group called "stable-maint-core" group, however, in recent years this responsibility has been devolved to the projects themselves. Each project with a stable branch now has a project- specific stable maintenance Gerrit group called PROJECTNAME-stable-maint (e.g. nova-stable-maint [2]. The issue here is who should *own* these groups. The owner of a Gerrit group is the only one that's able to modify it. In general, the owner of a Gerrit group is the group itself so for example the owner of python-openstackclient-core is python-openstackclient-core [3]. This means that if you're a member of the group then you can add or remove members, rename the group, set a description etc. However, _most_ PROJECTNAmE-stable-maint groups are owned by the old 'stable- maint-core' group, meaning only members of this global group can modify the project-specific groups. I say _most_ because this isn't applied across the board. The following projects are owned by 'stable-maint-core': * barbican-stable-maint * ceilometer-stable-maint * cinder-stable-maint * designate-stable-maint * glance-stable-maint * heat-stable-maint * horizon-stable-maint * ironic-stable-maint * keystone-stable-maint * manila-stable-maint * neutron-stable-maint * nova-stable-maint * oslo-stable-maint * python-openstackclient-stable-maint * sahara-stable-maint * swift-stable-maint * trove-stable-maint * zaqar-stable-maint However, the following stable groups "own themselves": * ansible-collections-openstack-stable-maint * aodh-stable-maint * congress-stable-maint * freezer-stable-maint * karbor-stable-maint * mistral-stable-maint * neutron-dynamic-routing-stable-maint * neutron-lib-stable-maint * neutron-vpnaas-stable-maint * octavia-stable-maint * openstacksdk-stable-maint * oslo-vmware-stable-maint * ovn-octavia-provider-stable-maint * panko-stable-maint * placement-stable-maint * sahara-dashboard-stable-maint * senlin-dashboard-stable-maint * senlin-stable-maint * telemetry-stable-maint This brings me to my question (finally!): do we want to resolve this discrepancy, and if so, how? Personally, I would lean towards delegating this entirely to the projects but I don't know if this requires TC involvement to do. If we want to insist on the stable-maint group owning all PROJECT-stable-maint branches then we have a lot of cleanup to do! Cheers, Stephen PS: This might be a good moment to do a cleanup of members of various stable branches that have since moved on... [1] https://docs.openstack.org/project-team-guide/stable-branches.html [2] https://review.opendev.org/admin/groups/21ce6c287ea33809980b2dec53915b07830… [3] https://review.opendev.org/admin/groups/aa0f197fcfbd4fcebeff921567ed3b48cd3…

4 6

[TripleO] PTL outage
by James Slagle 09 Jul '22

09 Jul '22

Hello TripleO, I'll be out on PTO for the next 2 weeks. Not that I'm typically needed :), but If anything urgent requires attention, please reach out to the kind folks directly in #tripleo. -- -- James Slagle --

1 0

[release] Release countdown for week R-12, Jul 11 - 15
by Előd Illés 09 Jul '22

09 Jul '22

Development Focus ----------------- The Zed-2 milestone is next week, on July 14th, 2022! Zed-related specs should now be finalized so that teams can move to implementation ASAP. Some teams observe specific deadlines on the second milestone (mostly spec freezes): please refer to https://releases.openstack.org/zed/schedule.html for details. General Information ------------------- Libraries need to be released at least once per milestone period. Next week, the release team will propose releases for any library that has not been otherwise released since milestone 1. PTL's and release liaisons, please watch for these and give a +1 to acknowledge them. If there is some reason to hold off on a release, let us know that as well. A +1 would be appreciated, but if we do not hear anything at all by the end of the week, we will assume things are OK to proceed. Remember that non-library deliverables that follow the cycle-with-intermediary release model should have an intermediary release before milestone-2. Those who haven't will be proposed to switch to the cycle-with-rc model, which is more suited to deliverables that are released only once per cycle. Next week is also the deadline to freeze the contents of the final release. All new 'Zed' deliverables need to have a deliverable file in https://opendev.org/openstack/releases/src/branch/master/deliverables and need to have done a release by milestone-2. Changes proposing those deliverables for inclusion in Zed have been posted, please update them with an actual release request before the milestone-2 deadline if you plan on including that deliverable in Zed, or -1 if you need one more cycle to be ready. Upcoming Deadlines & Dates -------------------------- Zed-2 Milestone: July 14th, 2022 Next PTG: October 17-20, 2022 (Columbus, Ohio) Előd Illés irc: elodilles

1 0

[cinder] Spec Freeze Exception Request
by Gorka Eguileor 09 Jul '22

09 Jul '22

Hi, I would like to request a spec freeze exception for the new Cinder Quota System spec [1]. Analysis of the required spec changes needed to implement the second quota driver, as agreed in the PTG/mid-cycle, were non trivial. In the latest spec update I just pushed there are considerable changes: - General improvements to existing sections to increase readability. - Description of the additional driver and reasons why we decided to implement it. - Spell out through the entire spec the similarities and differences of both drivers. - Change in tracking of the reservations to accommodate the new driver. - Description on how switching from one driver to the other would work. - Updated the driver interface to accommodate the particularities of the new driver. - Updated the performance section with a very brief summary of the performance tests done with some code prototipe. - Updating the phases of the effort as well as the work items. Cheers, Gorka. [1]: https://review.opendev.org/c/openstack/cinder-specs/+/819693

2 2

[neutron] CI meeting on Tuesday 12.07.2022 cancelled
by Slawek Kaplonski 08 Jul '22

08 Jul '22

Hi, I will be on PTO next week. As there is nothing really critical to our CI currently, lets cancel next week's meeting. See You on CI meeting on Tuesday 19th of July. -- Slawek Kaplonski Principal Software Engineer Red Hat

1 0

[baremetal-sig][ironic] Tue July 12, 2022, 2pm UTC: "Bare metal Kubernetes at G-Research"
by Arne Wiebalck 08 Jul '22

08 Jul '22

Dear all, The Bare Metal SIG will meet next week on Tue July 12, 2022, 2pm UTC featuring a topic of the day presentation by Scott Solkhon & Jamie Poole: "Bare metal Kubernetes at G-Research" Everyone is welcome, all details on how to join can be found on the SIG's etherpad: https://etherpad.opendev.org/p/bare-metal-sig Hope to see you there! Arne -- Arne Wiebalck CERN IT

1 0

[nova][neutron] do not recheck failing nova-next or nova-ovs-hybird-plug failures.
by Sean Mooney 08 Jul '22

08 Jul '22

hi o/ it looks like neutron recently moved linuxbridge to be experimental Jul 06 16:21:46.640517 ubuntu-focal-rax-ord-0030301377 neutron-server[90491]: ERROR neutron.common.experimental [-] Feature 'linuxbridge' is experimental and has to be explicitly enabled in 'cfg.CONF.experimental' we do not actully deploy it in nova-next or nova-ovs-hybrid-plug but it is enabeld in our job config as one of the configured mech drivers even if we dont install the agent. i have not looked up what change in neutron change this yet but im going to propose a patch to nova to disable it and i likely need to fix os-vif too so if you see a post fialure in either the nova-next of novs hybrid plug jobs (and or look into it and see " die 2385 'Neutron did not start'" in the Run devstack task summery that is why this is failing. ill update this thread once we have fixed the issue.

2 3

Cluster management tool for Openstack
by KK CHN 08 Jul '22

08 Jul '22

List, 1. Is there any specific tool or project component available to maintain multiple OpenStack Clusters 2. Is there any concept of Supervisory cluster ? Regards, Krish

1 0

Nova-conductor is having trouble with AMQP authentication
by Airamek 08 Jul '22

08 Jul '22

Hello everyone! I've installed OpenStack Ussuri on my home servers (one controller and one compute node, both running OpenSuse Leap 15.3) based on the instructions in the docs(https://docs.openstack.org/install-guide/openstack-services.html#minim… Everything works until I launch an instance in Horizon. The instance gets stuck on "Scheduling". Looking trough the logs I've came across nova-conductor.log(on the controller), which contained the following error log(full log in the attachments): 2022-07-08 00:48:08.846 25886 ERROR oslo_messaging.rpc.server [req-eb225ffd-9b12-4e80-987b-34f0317082c6 741cb0b6280cb6fbedf1d8c6df4fc854b3e177e331441e019b961839089154d6 9b41f3e228984401a7642f94cd47dc73 - 4596c7f3b97740b3adfa8f82b6240654 4596c7f3b97740b3adfa8f82b6240654] Exception during message handling: amqp.exceptions.AccessRefused: (0, 0): (403) ACCESS_REFUSED - Login was refused using authentication mechanism AMQPLAIN. For details see the broker logfile. I'm 100% sure my RabbitMQ username and password are set correctly in nova.conf. I've included my nova.conf too, with the passwords removed. I would be really thankful, if someone could point me in the right direction! P.S: Please excuse me for any grammatical or spelling mistakes, English is not my first language.

1 0