Hi all,
We had TC PTG sessions during the vPTG last week. I'm going to give an extremely high level summary of topics/action items here, as always for full context please see the etherpad: https://etherpad.opendev.org/p/apr2024-ptg-os-tc -- and, as always, remember TC decisions are made via gerrit patches; PTG conversations just help us rapidly spin up context for input to those decisions.
# TC <> Community Interaction session
Job failures were a hot topic during this session, with TC and community members discussing strategies for helping newer contributors troubleshoot and understand the importance of troubleshooting intermittent gate failures. Several suggestions were made, but no concrete actions were identified to take.
Getting things done in Openstack / 'modernization' was the other topic discussed in this session. Some contributors identified that changes such as more strict typing may not be considered a straightforward benefit over duck-typed python. Generally there was no conclusion here either for the whole of OpenStack, however, individual projects should not feel like they need to wait for "permission" to perform these kinds of modernization activities.
# OpenStack - where are we, where are we going
## User Survey Analysis
Slaweq summarized the user survey in a governance patch, https://review.opendev.org/c/openstack/governance/+/900516, as usual (thank you!) and the TC members and community discussed it. It was noted that as he was summarizing the survey results, Slaweq indicated he found some comments which went against community spirit, attributing a lack of contribution to "not helping competition". Some of the other comments were around data and the validity thereof; such as the 24% of users who responded they don't upgrade OpenStack potentially answering that because they replace the cluster in-place.
ACTION: Goutham volunteered to help reword the questions to avoid pitfalls mentioned during the session.
## Re-Visioning OpenStack aka "What is OpenStack Now"
JayF, in proposing this topic, suggested that the mission of OpenStack had gotten so large, and the projects so varied, that it's difficult to know what OpenStack itself means -- much less manage it as a whole. This reality was potentially proven via the unfixed Murano CVE during the last cycle. We had some discussion around what being in OpenStack means, and it was reiterated that OpenStack projects are not required to have security issues managed by the VMT or their process. It was pointed out that one of the side effects is that it's difficult to determine what common OpenStack components to teach given the number on the periphery. There was a suggestion that the TC should be doing project reviews to address this concern, but no concrete action was taken.
# TC - Specific new governance issues
## Affiliation Diversity Handling in OpenStack TC
As most reading this likely already know, during the last TC election there was an issue where affiliation diversity requirements combined with the elected TC members came into conflict. While Bauzas resolved this conflict by stepping aside, we want to prevent this kind of situation from deadlocking in the future.
There was a large amount of async discussion and comments on this topic, so I hesitate to summarize them here. Please review the etherpad directly for the myriad of ideas and issues presented by the large amount of engagement in this issue.
ACTION: gmann offered to propose guidelines for resolving this in the TC charter.
## Raising the bar for Activity This topic was proposed in response to the Murano CVE and the PTL not participating in a security fix. This raises the question as to how we assessed Murano was an active project, and how to prevent this kind of issue in the future.
No consensus was reached on any of the larger-scoped items, however, it was indicated by Julia that the new Cyber Resiliancy Act guidelines, when they are released, may require us to take some kind of action on this front.
There were some small items which garnered consensus, such as marking all leaderless projects as inactive by default -- as originally discussed in the 2024.1 PTG.
This was another very active discussion with lots of both sync and async engagement -- I strongly suggest you read the direct comments for this topic to get a full feeling of the breadth of this issue.
ACTION: https://review.opendev.org/c/openstack/governance/+/914726 was proposed by gmann, which implements the consensus idea to mark leaderless projects as inactive by default.
## Eventlet/AsyncIO migration goal This issue was raised to give a venue for https://review.opendev.org/c/openstack/governance/+/902585 to get synchronous comments/discussion.
Dan indicated he had not voted in favor of the change, and didn't plan to until he felt it had a reasonable likelihood to succeed in OpenStack -- early tests of this functionality failed. Jay indicated that his primary concern was elimination of eventlet; the new maintainer group does not plan on keeping eventlet alive forever. Bauzas pointed out that this is more than a goal -- we need dedicated effort in order to execute on this idea. Sean Mooney indicated that we need a non-wsgi service to migrate as an example.
Along these lines, we had agreement to reduce scope of the goal to remove eventlet dependencies/requirements from shared OpenStack libraries to enable individual projects to have an easier time with proof of concepts, and revisit the larger goal after such a proof of concept exists.
ACTION: JayF to propose a new, smaller scoped goal around removing eventlet dependencies.
# Follow-ups from Ongoing TC Activities
## Unmaintained Migration pain points There have been some lingering pain points while migrating from the Extended Maintenance model to Unmaintained.
Firstly, despite these branches being "unmaintained", we've set a minimum requirement of green CI with no Zuul config errors in order for a project to continue having their branch open for submission. This does not dictate a minimum level of testing; only that such tests are running and passing. These issues must be repaired in order for an unmaintained branch to remain open, but there are significant numbers that are failing. Please see Elod's recent email to the list for more information and deadlines on these cases.
Secondly, tooling for unmaintained branch EOL still needs to have automation completed -- the etherpad contains a full list of the items needed. This goes along with the overall sentiment of this session: the unmaintained branch migration has created an enormous amount of extra work.
ACTION: Please go look at Elod's email! This email being sent was a primary action related to this PTG session.
## PyPI Maintainer Cleanup The PyPi maintainer cleanup effort, detailed here: https://etherpad.opendev.org/p/openstack-pypi-maintainers-cleanup has been ongoing for over a year. As of March 15, 2024, we still have 232 project/maintainer pairs to cleanup and 110 separate humans who have access to at least one openstack pypi deliverable.
The TC discussed next steps; consensus was that in cases where openstackci holds owner permissions, we are in favor of using those permissions to cleanup where possible. However, in cases where openstackci does not hold owner permissions, it gets a bit more difficult and we have fewer options: either engage with the PSF's process to recover the pypi account, which could take months; or migrate to a different pypi deliverable name. Both are difficult and time-consuming.
ACTION: TC to encourage PTLs to once again reach out to any pypi owners/maintainers who have not yet acted to attempt to cleanup their access.
## Revise the project inactive state process This was some specific, targeted discussion around if we needed to revise inactive policy to include the case which happened to Murano -- because our process dictates that inactive projects are only removed from the release prior to milestone-2, finding out Murano was inactive and removing it from the release after M-2 was a special case.
This discussion centered primarily around whether any revision to the policy was needed. In the end, no specific action items were created.
## Leaderless projects Details on this item are in https://etherpad.opendev.org/p/2024.2-leaderless and have been sent to the list separately.
# Allowing other languages for client facing tools (rust) Notes in the etherpad for this topic was minimal. Essentially, there is no restriction on what languages can be used -- the runtimes document is meant to be specific information about those languages, not restricting other languages that could be used.
There were two primary concerns around this item, JayF asked why we were looking into new rust-based tooling instead of integrating with the existing openstack-rust community. Other contributors expressed concerns around being able to understand or debug code in different languages.
No action items came out of this discussion.
# OpenAPI in OpenStack There was minimal discussion around this item. There appeared to be clear consensus with moving forward with OpenAPI on a project-by-project basis, with any efforts towards creating a goal being pushed until after there is more adoption.
# Deprecate all native clients in favor of OpenStackSDK/openstackclient Again, minimal discussion on this item. There seemed to be little objection to just getting it done, but there were no immediate volunteers to do the work. See the etherpad for some specific examples of gaps that need to be resolved.
Thank you all for participating in the TC PTG. Please do not let these items fall by the wayside; if you had an idea that didn't reach consensus in the PTG, one possible way to move it forward is a concrete proposal where folks can discuss -- either to the governance repo, or to the mailing list.
-- Jay Faulkner OpenStack TC