Open Stack

Hello Everyone,

I am summarizing the Technical Committee discussion that happened in the Yoga cycle PTG last week.

Recordings:
Day1: https://www.youtube.com/watch?v=uQRKYummsHM
Day2: https://www.youtube.com/watch?v=IHj7cpBlbYo
Day3: https://www.youtube.com/watch?v=RT492bi6Xto 

TC + Community leaders interaction
------------------------------------------
This is our first session in PTG to interact with community leaders and ask for feedback on TC.
Below are the topics we discussed in this feedback session

* What is TC responsibility:
This is the first feedback we started this session, to discuss what is the role of TC other than accepting/
removing the projects and community-wide goals. does TC need to have a strong vision and start
working on that? Why not TC do more technical work than spend time on composing resolutions or so?

All those were valid points and we all agreed that TC should be doing more technical work and providing
more guidance to the community on the cross-project works for example RBAC, Unified limit (more of
similar way API SIG is doing on API side).

* Improving community-wide goal process:
Another feedback was on the effectiveness of community-wide goals. A few of the community-wide goals
were not ready when they were selected. Even a few like pdf goal changed the implementation in
milestone-2 and projects have to update the previous implementation. Or sometimes we try too much to do
instead of small steps like IPV6 testing. With all feedback, we agreed to have a more concrete checklist when
we select any goal and also check project bandwidth to complete the work.  

* Fewer contributors:
Fewer contributors issue is from many projects, to solve that at some extent, TC will encourage projects to
apply in outreachy/mentorship programs where few projects have received a good amount of help.

* Improving CI:
Improving CI is the next topic which we discussed in TC slots on Thursday. One key topic in this was
"Request to be able to recheck on a single test instead of the whole check test" as many projects like Ironic
gate has more often neutron failure and they have to recheck the complete set of jobs. The issue can be from
DHCP, memory etc. We do not think allowing job-specific recheck is the right direction here and instead, we
should encourage projects to solve the failures we get in the gate which can improve the code stability. Also, we
should encourage projects to monitor the gate failures. 

>From the above discussion, we are taking below two action items for TC:

1. TC to start composing the technical guidelines on various topics like 'unified limit' etc similar way API SIG has done.
2. TC to add a more specific checklist for community-wide goal readiness and make them more successful as they
 are currently. 


TC interop sync on guidelines
-----------------------------------
We discussed interop tests requirements.  One of the points brought that if starter kits impact interop
guidelines to consider but it does not. Can cinder be separated from "OpenStack Powered Compute" if it
can be used as standalone? The Interop team need to check if there are cloud without cinder and how they
apply for interop certification. On tests requirement by interop, our current process stays same that if interop
defined  the capabilities in new guidelines then the test writing can be requested or even an interop group can
propose the test in Tempest or Tempest plugins.


Technical Writing (doc) SIG need a chair and more maintainers
-----------------------------------------------------------------------
We are merging this SIG repo into TC responsibility. There are not many activities nowadays on this SIG or repo
it own so it should not impact the TC work as such. We agreed to distribute this SIG repo in

* TC: api-site, constellations, and openstack-manuals repos under 
* FC SIG: contributor-guide, training-guides, and upstream-institute-virtual-environment
* For training-labs which is for COA, I will check with Foundation on ownership or it.

Thanks, Stephen for serving as chair for this SIG.


Yoga testing runtime: Review & Update if needed
----------------------------------------------------------
We discussed/iterate over the Yoga testing runtime on new distro and python versions
to tests.

Distro to tests: 
* We agreed on including "Debian Bullseye" as a distro in the testing runtime.
* centos9-stream release time is not clear so we are keeping centos8-stream for now.
* centos8 is planned to be EOL at end of 2021, If you see failure on or stable branch testing,
   then you can update it to centos8-stream (devstack support is already there) But we do not need to change
   the testing runtime for stable branches as such.

Python Versions to test:
* py3.8 as voting (no change from currently tested)
* py3.9 as voting
* py3.10 as non voting.
* keep  py3.6 until we move from centos8-stream to centos9-stream

I will update the testing runtime doc and job template for that.


TC tags review
------------------
You might have seen the email from yoctozepto about a query on TC tag usage[1]. As we did not get any
response in the email, we did final checks in PTG. We agreed to start the tag framework removal proposal
on ML and if there is no objection for a week or so then we will remove it.


Improvement in project governance
------------------------------------------
In the past couple of cycles, we have seen few projects that are not so active or not getting more attention
from users. This discussion was to brainstorm the process to keep monitoring such projects and especially
when there is a new project application how we can monitor those in initial time to check if they have all the
required things working to stay as official OpenStack project.

The first thing we discussed introducing the different levels of the project something similar to CNCF (sandbox,
incubated, graduated) or OpenStack used to have (incubation -> incubated projects). But it is not known if
these levels will work well in our governance. 

With the low cost to maintain projects in OpenStack governance (as long as they are active). Being an OpenStack
official project is one way to give that project more visibility in the market and attract users/contributors.

With all these points, we agreed not to introduce the different levels in the project hierarchy but we will
introduce a new process of 'Tech Pre-review' for new project applications so that we can monitor the new
projects if they are doing good and all minimum required things are working smoothly. As the next step, we
will be working to define the "Tech Pre-review" checklist and timeline etc.


Release name process change 
-----------------------------------
We want to discuss two points 1. allow community members to vote on release name 2. some pre-trademark
(non-paid) checks, in this topic but due to time limit we discussed first only.

As you might know, we changed the electorate on release naming from community to TC which has been
objected to in the past when we changed it and during the naming voting also in the past couple of cycles.
We have simplified the name proposal criteria in the past which solved the issue that occurred in past on
TC removing the name.

We agreed on:
* The community can propose names that meet the convention.
* The TC will ensure that the name is not offensive based on community feedback. 
* Allow community members to vote on the proposed names.
* After Z cycle, go back to 'A' and go through the alphabet (obviously don't re-use names).


Pain Point targeting
-----------------------
Two key pain points we collected during TC weekly meetings were 1. Rabbitmq 2. OpenStackClient support.
But the etherpad has a lot more pain points not only from projects but also from operator or project has
collected those from operators. We need to iterate the list again which we will continue doing in TC weekly
meetings. TC members will encourage projects to fix or have a look into those pain points if the operator has
added them. TC also can help a few of the pain points to solve consistently by defining the technical guidelines
for such common pain points.  As the next step, we will continue reviewing the list in etherpad[2].


'Skyline' application to become an official OpenStack Project
------------------------------------------------------------------------
We discussed the new project application Skyline which is a dashboard project for OpenStack. One of the key
points raised is about non-integrated projects UI-plugins (like every project has horizon plugins for their UI).
How and who is going to implement the new UI plugins on the project's side?

Also, there is more work needed on repos and python packaging side for which discussion is going in separate
mailing thread[3].

Overall, we are ok to proceed with the proposal once the python package/repos things are set up correctly.


Discussion on new RBAC
------------------------------
There were a lot of discussions on the new RBAC on various project sessions. it was clear from the discussion
or points raised in those sessions that we are not using the system scope in the way it should be used. We
should keep system-level operation only for system scoped and project level for the project. If any system users
want to perform the project level operation then they can request the project token and then request.

Also, 'admin' term at all levels domain, system, and the project is the most confusing term and we would like to change
that to 'manager' or so. The discussion is not yet over and due to the time limit, we wanted to continue it after PTG too.

As a summary, we selected this (current way) as Yoga cycle goal which we will re-iterate. I will set up the call to
continue the discussion and send on openstack-discuss mailing list.

For a detailed summary, please refer to L122 in policy popup etherpad[4].


Community-wide goals
----------------------------
Based on the feedback received in TC+community leaders sessions, we would like to make sure we have the
proper checklist to know this goal is ready to start (in terms of implementation details as well as projects bandwidth).
Rico and I had worked on such a checklist in the past but did not push for review which we should do now.

We are also restructuring the community-wide goal timeline by decoupling them from the release cycle. At a time
we will select one or more goals to start with one or more milestones. They can be multi-cycle goals or single based
on the goal nature and work it needs. This way we will make sure that we complete the work needed to be done
for that goal irrespective of the current cycle release.


Xena Retrospective
-----------------------
What went well?
* Xena cycle tracker status: Completed the 9 items out of 13, others in progress.
* Think having the weekly meetings went well instead of just office hours.
* Got good feedback from the community about what they expect from the TC.
* We have been good at keeping our open reviews low.
What to change or any other feedback?
* Be more technical, provide more technical guidance.
* Get a feedback loop from the community and work on that feedback. 


Pop Up Team Check In
----------------------------
* Secure RBAC / Policy 
As discussed in RBAC discussion, there are a lot of work still needed along with community-wide goal. We decided
to continue this pop-up team for the Yoga cycle at least.

* Encryption
Slow progress but still more work to do (waiting on changes in Barbican). The Team is hoping for more
progress in the coming cycle. We will continue this pop-up team.


Meeting check
-----------------
We will continue the weekly meeting at the same time they are currently and also continue the monthly video
call. We will continue using google meet until we figure out the recording things in meetpad or so. We did not
discuss or check on office hours whether to continue those or not which we will continue in weekly meetings.


User Survey Feedback Responses
---------------------------------------
We will start working on analyzing the feedback from the user survey. Jay will summarize the feedback and
then we will start composing the action items accordingly. 


k8s Steering Committee Cross community Discussions
-----------------------------------------------------------------
This is our last hour of the PTG. This is cross-community sessions we continue organizing in PTG. From
Kubernetes steering committee, we had Dims, Bob, Christoph joined along with OpenStack TC and a few non-tc
members.

The first topic we talked about is the different levels in the CNCF ladder and project confirmation process. This area is
mostly taken care of by CNCF and Kubernetes community more concentrate on the technical part. Like OpenStack,
Kubernetes is also seeing a slow down in project/SIG activities especially on community leaders. Kubernetes
is trying mentor/cohort and more distributed roles by documenting the responsibility of that role that will
help contributors to discuss it with their employer.

OpenStack Upstream investment opportunity is one of the things we discussed and how successful that is. One of the
benefits of this is we can communicate the help-needed things on various platforms/forums.  ELK is one (the only
as of now) example of success. 

Like OpenStack, Kubernetes also lacks in CI/CD resourcing and funding. This seems like a common problem
in many OSS communities.


Yoga cycle tracker
----------------------
Like we did in Xena cycle, TC is defining the cycle-wise tracker to complete the set of things TC would like
to work on. For the Yoga cycle also we will continue with the tracker. Based on the PTG discussion, we have
collected 9 items for the Yoga cycle to complete.  I have captured those in the below etherpad which will be using
it for progress tracking also.
- https://etherpad.opendev.org/p/tc-yoga-tracker				


[1] http://lists.openstack.org/pipermail/openstack-discuss/2021-September/024804.html
[2] https://etherpad.opendev.org/p/pain-point-elimination
[3] http://lists.openstack.org/pipermail/openstack-discuss/2021-October/025397.html
[4] https://etherpad.opendev.org/p/policy-popup-yoga-ptg
[5] https://etherpad.opendev.org/p/tc-xena-tracker

-gmann