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

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

08 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 08 Jul '22

08 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 08 Jul '22

08 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 08 Jul '22

08 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

[neutron] Drivers meeting agenda - 08.07.2022.
by Lajos Katona 07 Jul '22

07 Jul '22

Hi Neutron Drivers, The agenda for tomorrow's drivers meeting is at [1]. * [RFE] Adding the "rekey" parameter to the api for strongswan like "dpd_action" (#link https://bugs.launchpad.net/neutron/+bug/1979044) * [RFE] Firewall Group Ordering on Port Association (#link https://bugs.launchpad.net/neutron/+bug/1979816) [1] https://wiki.openstack.org/wiki/Meetings/NeutronDrivers#Agenda See you at the meeting tomorrow. Lajos Katona (lajoskatona)

1 0