[tc][all][ Wallaby Virtual PTG Summary

Ghanshyam Mann gmann at ghanshyammann.com
Sat Oct 31 23:21:34 UTC 2020

Hello Everyone,

I am summarizing the TC PTG discussion and action items.

Wallaby Leaderless assignment
Four projects are still pending for leadership assignment. We discussed the next step. If you would like
to help any of these or using in your cloud/distro, this is the right time to step up:

1. Karbor
- Action item: diablo_rojo will start the retirement process.
2. Qinling
- Action item: gmann to start the retirement process.
3. Searchlight
-Action item: gmann to start the retirement process.
4. Placement
- Action item: gibi will update TC about the final discussion and accordingly mnaser to propose the patch
in governance.

Victoria Retrospective:
There are a couple of things TC finished in last cycle, few of them are:

* Reduced size of TC to speed up the things.
* Updated policy to add projects faster.
* Outlined Distributed Project Leadership Model as an alternate leadership solution of PTL.  Oslo will be the
first project to try this new model.
* Normalized retirement processes. All the retired repos cleanup is finished.
* Tag cleanups & additions This is not complete yet but started with tc-approved release tag in the Victoria cycle.
* Merged UC with TC. This is one of the key things finished and the best strategy to make users-developers work
more closely. 

TC Meeting time:
TC is going to try (re-try) the weekly meeting every Thursday 15:00 UTC.
* Action Items: mnaser: propose patch.

TC policy regarding OpenStack client:
Forum Discussion: https://etherpad.opendev.org/p/vSummit2020_FeatureGap

This is one of the important items and still no good progress on this. From TC perspective, we talked
about how to ask or motivate projects to migrate to OSC. TC needs to be very clear on whether it's a
strict policy or just guidelines.  After long discussion on this we are going with the below strategy:
These strategies will be documented as TC resolution.

* All user docs should have `openstack` client commands. 
* Focus on user docs first and then ops docs later
* All ci-tooling should have `openstack` client usage
* Use the process to find what is missing so we can prioritize it.

* Action items:
- diablo_rojo to work on initial resolution proposal[1]

Finalize the Wallaby cycle goal selection:
There are two proposals for the Wallaby community-wide goals. First is 'oslo.rootwrap to oslo.privsep'
which is already being discussed in the last cycle also and all set to be selected[2]. 2nd proposal came up
during PTG itself. During policy-popup PTG[3], it came up that deprecating the JSON formatted of policy
file will be a good advance step before the projects move to new RBAC policies. This will help operators
to smoothly migrate to new policies. This does not involve much work and ok to select as 2nd goal for Wallaby

TC agreed to have below goals for Wallaby cycle:
* Migrate from oslo.rootwrap to oslo.privsep [2]
* Migrate Default Policy Format from JSON to YAML [4]

- TC to merge the patches which selects both goals for Wallaby cycle.

TC tag cleanup:
In the Victoria cycle, we started the process to audit all the TC tags and start cleanup those. We
removed the 'tc:approved-release' tag in the Victoria cycle[5]. In this PTG we discussed two more tags.

1. assert:supports-zero-downtime-upgrade:
Currently, there is no project who has this tag and also no testing framework available. Testing for
zero downtime is not so easy in upstream testing.  We decided to remove this tag as it is advertising
something we aren't doing. If anyone interested to spend time on this in the future then we can add
it after projects start testing it and document it.

2. assert:supports-api-interoperability:
This tag is whether project API is interoperable also or not and this is important from the interop trademark
program also. We only have Nova having this tag. Our goal is to promote more projects to apply for this tag.
During the discussion, we found that we need to clarify this tag more clearly. For example, this tag is not
about implementing the microversion but any versioning schema which provides the feature (API changes)
discoverability. And also it is about how we change the API not how our APIs are currently. As long as services
have some versioning mechanism to discover the changes and follow the API SIG guidelines for interoperability,
and test it via branchless testing way, that service is applicable to apply for this tag.

TC will document this tag in a more clear way and encourage each project to start working on applying this tag.

* Action:
- Graham to put up a change to update the wording to allow for discovery mechanisms[6]
- Should include the release in which they started to assert this tag.
- also documents that it's about following the guidelines for future changes not existing one. - gmann
- Should socialize this out to the projects after we get the documentation improvements landed. - gmann

k8s Community Bridging :
This is one of the exciting discussion for everyone. We hosted this cross-community meeting with Kubernetes
steering committee teams. Bob and dims from the Kubernetes steering committee joined us in this discussion.
It was started with a quick introduction from both teams and then started the discussion on the below topics [11]

* Sharing governance models:
k8s governance hierarchy is LF->CNCF->k8s steering commitee->various SIG/working group. k8s Steering
the committee consists of 7 elected members and doesn't actually influence the direction of the code instead
leave it to SIG and arch committee. There is no chair in this committee and host biweekly private as well as
public meetings. 
Each SIG (repos) team has approver and reviewer roles where reviewer review the code and approver are
responsible for merging the code.

Naser explained the OpenStack governance model. 

* What are your 3 biggest issues that are barriers to growth/sustainability as a community? as a project?
 - Going up the contribution ladder is hard.
 - Stale/emeritus membership in reviewer/approver level groups.
 - Mono repo makes it so that each SIG involved needs to review which can slow things down.

* Area/Domain mapping vs service/repo centered teams
- mono repo forces people to work together and it's a little more diverse who is reviewing
- mono repo is bad because sometimes things need to be in multiple places like documentation
- mono repo struggles with libraries especially on testing the external one.

* Related Ecosystem projects comparisons
The SIG lead has to sign off and accept that they are willing to take ownership + handle maintenance + releasing
etc. It is general consensus that we try to distribute much work as possible to the subgroup and keep it out of k/k.
There is general consensus across k8s leadership that work should be delegated out to subgroups. For API
interoperability challenge in a distributed model, k8s has conformance tests which exercise the API performance
and vendors try and upload conformance results every release or dot release.

* Common FOSS topics
release and CI part was discussed. and also on how COVID things are impacting community health. k8s community
almost lost their independents or part-time contributors. also, the k8s community is doing 3 releases per year
compared to 4. 

* Staying connected going forward
To stay connected it will be a good idea if we extend an invite for K8s to join PTG.

Upstream Investment Opportunities:
We have three upstream opportunities defined for 2020[1] but there is no help on any of these, even
in previous (2018, 2019) upstream opportunities also. We started the discussion if we need to continue
this for 2021 years also or just stop defining it and decide the area to help when we have someone interested.
Before deciding anything on this mnaser will discuss this with the board of directors and get their opinion.

* Action Items:
- mnaser to find ways to engage with members and talk with them.
- mnaser to talk to board about infrastructure
- mnaser to talk to board about platinum members contribution levels + what are they doing to drive engagement.

Pop Up Team Check In:
Currently, we have two active popup teams 1. policy 2. Encryption. TC checked the progress
on both teams. The policy team is very active and finished some work in Voctoria cycle (cyborg
finished it and Barbican started) and also hosted forum[8], PTG sessions[9], and discussed
Wallaby development plan. This team host biweekly meeting to discuss and review the progress.
The encryption team is also active. Josephine explained the progress on this. Glance spec is merged. 

Both teams will continue in Wallaby cycle also.

Completing the Gerrit breach audit :
There are still 19 teams pending to finish this audit. Those are listed in etherpad
- https://etherpad.opendev.org/p/code-audit-gerrit-breach-tracker

We encourage all those pending teams to finish the audit, TC members will start following
with those projects every week.

* Action:
- TC to follow up every week on progress

Other topics:
We ran out of time and all the pending (below) topics will be discussed in TC regular meetings. TC will skip
this month's meeting[10] but will have weekly meetings on 12th Nov onwards.

*Better way to test defined testing runtime
*Monitoring in OpenStack: Ceilometer + Telemetry + Gnocchi state
*Stable core team maintainer and process to recruit the new members and adding core team members in stable core list.

Detailed discussions are in this Etherpad: https://etherpad.opendev.org/p/tc-wallaby-ptg

[1] https://review.opendev.org/759904
[2] https://review.opendev.org/#/c/755590/
[3] https://etherpad.opendev.org/p/policy-popup-wallaby-ptg
[4] https://review.opendev.org/#/c/759881/
[5] http://lists.openstack.org/pipermail/openstack-discuss/2020-October/017786.html
[6]  https://review.opendev.org/760562
[7] https://governance.openstack.org/tc/reference/upstream-investment-opportunities/2020/index.html
[8] https://etherpad.opendev.org/p/consistent-and-secure-default-policies-wallaby
[9] https://etherpad.opendev.org/p/policy-popup-wallaby-ptg
[10] http://lists.openstack.org/pipermail/openstack-discuss/2020-October/018439.html
[11] https://etherpad.opendev.org/p/kubernetes-cross-community-topics


More information about the openstack-discuss mailing list