[openstack-dev] [tc] Technical Committee Status update, March 9th

Thierry Carrez thierry at openstack.org
Fri Mar 9 10:28:25 UTC 2018


This is the weekly summary of Technical Committee initiatives. You can
find the full list of all open topics (updated twice a week) at:


If you are working on something (or plan to work on something)
governance-related that is not reflected on the tracker yet, please feel
free to add to it !

== Recently-approved changes ==

* Add PowerStackers project team [1]
* Add resolution about CI for external projects [2]
* Add naming poll info for S release [3]
* Fix small oversight in Python PTI for tests [4]
* Goal updates: glance
* New repos: openstack-ansible-nspawn_hosts,
openstack-ansible-nspawn_container_create, puppet-monasca,
openstack-ansible-os_panko, rally-openstack,
* Removed repo: horizon-cisco-ui

[1] https://review.openstack.org/540165
[2] https://review.openstack.org/545065
[3] https://review.openstack.org/545010
[4] https://review.openstack.org/545639

Major news here is the final approval of the PowerStackers project team,
dedicated to providing OpenStack support for the POWER CPU architecture:


The Technical Committee also approved a resolution to define acceptable
usage of OpenStack CI resources to the testing of other projects:


== TC track at the PTG ==

We held a track on Friday at the PTG to discuss Technical Committee
initiatives and more generally OpenStack-wide and governance issues.
Here is a quick summary of what happened there.

We started with a retrospective of how we got things done so far with
this membership. Async collaborations worked well, and the weekly
reports were seen as helpful. We should probably try to steer the topic
of discussions in office hours a bit more. We also need to more
consciously track progress on TC initiatives, with something to stand
between the vision and the individual changes posted to implement it.
Using a task tracker (StoryBoard) was suggested. We should also make
sure to have more than one member on the TC being able to apply approval
rules on the governance repository, so that the chair does not block
everything while they take time off.

After that we reviewed progress against the vision. Most progress has
been made on the "engaging with adjacent communities" front.
Constellations are still waiting for their first practical application.
Dims volunteered to drive one around containers. Situation on the
diversity front has been improving, although we could always do better.
We should encourage everyone to push people they see as great candidates
to run. As far as growing new leaders goes, we had some success getting
new people to step up and champion goals. We need to encourage those
(thanks email from Foundation, success story articles).

Next topic was reviewing community goals, and how to improve the
selection process and wider community engagement around them, as well as
how to provide more active support to those who step up to champion
them. From there we switched to discussing base services. The addition
of etcd to the OpenStack base services did not exactly trigger wide
adoption of it yet, for various reasons. We discussed various ways to
make it finally pass that critical mass that would make everyone more
comfortable leveraging it.

Then we switched to reviewing the concept of maintenance mode and our
usage of team diversity tags. Maintenance mode was still seen as a
useful status to communicate to consumers of OpenStack, and we discussed
ways to sustainably maintain "stable" projects over the long run. The
team diversity tags, on the other hand, were designed with metrics that
fit the 2014 growth pattern, but are not so great in a landscape with
more stable components maintained by smaller teams. We might want to
replace them with regular (qualitative rather than quantitative)
organizational diversity reports that would provide better insights.

Final topic of the morning was the Python 2 deprecation process, with
next-gen operating systems more and more likely to drop Py2 earlier
rather than later. We discussed the current state of the transition and
decided to come up with a clearer timeline (some mentioned the need for
all of OpenStack to support Python 3 by the T release, Q3 2019).

On the afternoon we discussed the resolution about stable branch EOL and
"extended maintenance" that was discussed earlier in the week. In
particular we discussed the ability for project stable maint teams to
retain control over their stable maint story, and avoid having two
completely separate teams producing the same component. The discussion
on this continued on the review (see below).

Then we discussed the tc-approved-release tag. It's a technical tag used
to communicate to the board the set of projects that we are fine with
them potentially including in trademark programs. However the name of
the tag makes people read too much into it, and makes it difficult to
remove things from it. Creating a new tag more specifically around
trademark program admissibility might be a way to fix it. From there the
discussion moved to discuss the Interop tests location issue (more on
that below).

Before our brains turned into complete mush, we also discussed the
impact on OpenStack of the OpenStack Foundation support to new strategic
focus areas. It creates an opportunity to focus OpenStack on the open
cloud infrastructure use case (calling other by-products like our CI/CD
system under its own name). However we need to proactively engage with
other technical leaders in those areas (like the Kata Containers Arch
committee) in order to paint a good complementarity story.

For more details, you can find detailed notes on the following etherpad:


== Under discussion ==

The PTG rebooted the discussion to clarify how the testing of
interoperability programs should be organized in the age of add-on
trademark programs. During the TC track there was a new strawman
proposal (with agreement from some InteropWG, some QA, some Heat and and
Designate team members present) to have interop-specific Tempest plugins
co-owned by QA/Interop/add-on project team. mugsie amended his proposal


cdent did post his own simplified variant of the same strawman:


An alternative solution is to just say that the InteropWG should be able
to pick tests wherever they see fit. The environment has changed over
the past 4 years, so strong guidance from the TC as to where to find
tests might no longer be needed. mugsie posted this alternate option as:


The other hot topic under discussion is mriedem's resolution defining
"extended maintenance", as a result of the discussions on Tuesday
afternoon's "release cycles vs. downstream consumption models" track.
This resolution is trying to strike the right trade-off between
encouraging new resources to step up to maintain branches for a longer
period of time, avoiding schisms between project stable maint teams and
new extended maintenance resources, the need for a common understanding
of what we mean by stable branches (no feature backport) and making sure
we still test things and do not introduce regressions. Please comment at:


== TC member actions for the coming week(s) ==

We should establish an etherpad to discuss potential Forum sessions we'd
like to file for the Vancouver Summit.

== Office hours ==

To be more inclusive of all timezones and more mindful of people for
which English is not the primary language, the Technical Committee
dropped its dependency on weekly meetings. So that you can still get
hold of TC members on IRC, we instituted a series of office hours on

* 09:00 UTC on Tuesdays
* 01:00 UTC on Wednesdays
* 15:00 UTC on Thursdays

For the coming week, I expect discussions to be around the Interop test
location resolution(s) and the Extended maintenance proposal.


Thierry Carrez (ttx)

More information about the OpenStack-dev mailing list