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

[heat][horizon] heat-dashboard-core maintenance
by Akihiro Motoki 09 Jul '22

09 Jul '22

Hi, I added heat-core gerrit group to heat-dashboard-core [1]. Heat team and horizon team agreed to maintain heat-dashboard together a while ago and horizon-core was added to heat-dashboard-core. At that time heat-dashboard had active contributors so head-dashboard-core did not include heat-core team. The active contributors in heat-dashboard-core have gone and Rico is the only person from the heat team, so it is time to add heat-core to heat-dashboard-core. In addition, I would like to drop the following folks from heat-dashboard-core. They were active in heat-dashboard but they had no activities for over three years. If there is no objection, I will drop them next week. - Kazunori Shinohara - Keiichi Hikita - Xinni Ge [1] https://review.opendev.org/admin/groups/8803fcad46b4bce76ed436861474878f36e… Thanks, Akihiro Motoki (amotoki)

1 1

[all][tc] What's happening in Technical Committee: summary 08 July 2022: Reading: 5 min
by Ghanshyam Mann 08 Jul '22

08 Jul '22

Hello Everyone, Here is this week's summary of the Technical Committee activities. 1. TC Meetings: ============ * We had this week's meeting on 07 July. Most of the meeting discussions are summarized in this email. As it was video meeting, full recording is available @https://www.youtube.com/watch?v=zeJG6Mujalo&t=29s and brief logs are available @https://meetings.opendev.org/meetings/tc/2022/tc.2022-07-07-15.00.log.html * Next TC weekly meeting will be on 14 July Thursday at 15:00 UTC, feel free to add the topic on the agenda[1] by 13 July. 2. What we completed this week: ========================= * Nothing specific in this week. 3. Activities In progress: ================== TC Tracker for Zed cycle ------------------------------ * Zed tracker etherpad includes the TC working items[2], Two are completed and others items are in-progress. Open Reviews ----------------- * Three open reviews for ongoing activities[3]. CentOS-stream-9 testing stability and collaboration with centos-stream maintainers --------------------------------------------------------------------------------------------------- We discussed this topic in the TC meeting and I summarized the discussion in separate ML[4]. Create the Environmental Sustainability SIG --------------------------------------------------- Not much update on this except what we discussed last time, feel free to add your feedback in review[5]. Consistent and Secure Default RBAC ------------------------------------------- We have a good amount of discussion and review in the goal document updates[6] and I have updated the patch by resolving the review comments. 2021 User Survey TC Question Analysis ----------------------------------------------- No update on this. The survey summary is up for review[7]. Feel free to check and provide feedback. Zed cycle Leaderless projects ---------------------------------- No updates on this. Only Adjutant project is leaderless/maintainer-less. We will check Adjutant's the situation again on ML and hope Braden will be ready with their company side permission[8]. Fixing Zuul config error ---------------------------- Requesting projects with zuul config error to look into those and fix them which should not take much time[9][10]. Project updates ------------------- * None 4. How to contact the TC: ==================== If you would like to discuss or give feedback to TC, you can reach out to us in multiple ways: 1. Email: you can send the email with tag [tc] on openstack-discuss ML[11]. 2. Weekly meeting: The Technical Committee conduct a weekly meeting every Thursday 15 UTC [12] 3. Ping us using 'tc-members' nickname on #openstack-tc IRC channel. [1] https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting [2] https://review.opendev.org/c/openstack/governance/+/847413 [3] https://review.opendev.org/q/projects:openstack/governance+status:open [4] https://lists.openstack.org/pipermail/openstack-discuss/2022-July/029468.ht… [5] https://review.opendev.org/c/openstack/governance-sigs/+/845336 [6] https://review.opendev.org/c/openstack/governance/+/847418 [7] https://review.opendev.org/c/openstack/governance/+/836888 [8] http://lists.openstack.org/pipermail/openstack-discuss/2022-March/027626.ht… [9] https://etherpad.opendev.org/p/zuul-config-error-openstack [10] http://lists.openstack.org/pipermail/openstack-discuss/2022-May/028603.html [11] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss [12] http://eavesdrop.openstack.org/#Technical_Committee_Meeting -gmann

1 0

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

08 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 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