Recap of OpenStack Technical Committee Wallaby Virtual PTG, 2020

admin Open Source, OpenStack

Due to COVID-19 pandemic, OpenStack PTG for Wallaby development planning and discussions are held virtually from Oct 26 – 30th, 2020. Overall we had a good discussion and another successful virtual PTG though most of us missed the face to face interaction. This blog covers the TC discussion that happened on Tuesday and Friday.



    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

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


    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. 2nd proposal came up during PTG itself. During policy-popup PTG, 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 cycle,

TC agreed to have the below goals for the Wallaby cycle:

Action items:

  • TC to merge the patches which selects both goals for the 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. 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 Items:

  • Graham to put up a change to update the wording to allow for discovery mechanisms.
  • Should include the release in which they started to assert this tag.
  • 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:

  • 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 the reviewer review the code and the 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 have conformance tests that 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 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, PTG sessions, 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

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

Action Items:

  • 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 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.


You May Also Like..

10 Years of OpenStack – Ghanshyam Mann at NEC

While OpenStack celebrated its 10th Anniversary, here is my favorite memory from the last 10 years of OpenStack 10 Years […]

Recap of OpenStack Quality Assurance Xena Virtual PTG, 2021

OpenStack PTG for Xena development planning and discussions are held virtually from 19 – 23, April 2021. Overall we had […]

Recap of OpenStack Technical Committee Xena Virtual PTG, 2021

OpenStack PTG for Xena development planning and discussions are held virtually from 19 – 23, April 2021. Overall we had […]

Leave a Reply

Your email address will not be published. Required fields are marked *