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.
## Eventlet/AsyncIO migration goal
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
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
# 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