Open Stack

As I sit down to describe the highlights of the virtual OpenDev PTG of June
2020, the first thing I have to say is that the virtual participation is a two
edged sword.  On one hand, the spontaneity of the hallway track and the ability
to quickly drop in to another group's meeting were largely lost.  But I think
that there were some people in the Neutron room that would not have been able to
make it if the event was held in Vancouver.  Once the pandemic is in the rear
view mirror, I hope that we can resume in-person events.  But I think that there
is potential value to interspersing virtual events with the in-person variety,
to reach out to students, small companies, and ravel-averse companies or
individuals.  

I'd also like to say that the Foundation staff did a great job with running an
event that so completely broke from precedent.  The choice of two
videoconferencing platforms, with the ability of teams to select the one that
matched their needs the best, was foresighted since certain areas had access
issues with certain platforms.  

--- Technical Committee ---

I felt that the TC sessions at this PTG were very productive and valuable.  In
particular, we used the 'raise hands' feature in Zoom to ensure an orderly
exchange of views that gave everyone a chance to speak, and I felt that went
very well.  A few of the highlights of what the TC discussed and decided are:

1.) The TC decided to draft a policy change to provide a model for a project
without a PTL.  If an interested project was interested in changing to a
PTL-less model they could opt-in to such a model, but for projects that do not
opt in nothing would change.  When imagining how a project could function
without a PTL, we deconstructed the role into it's component parts, including:
interfacing with the release, infrastructure, and security teams; doing the
necessary prep work for PTG and summit events; acting as a public contact point
for the project; acting as the bug resolver of last resort.  Of these the only
ones that are essential from a TC perspective are the release liaison and the
infrastructure liaison (for CI issues); the VMT team already has a list of
subject matter experts they consult for vulnerabilities.  An events person may
be called for on a per-event basis - and if no one steps forward for a project,
then that project wouldn't be represented at that event.  There's definitely
more responsibility diffused within the project team in this model, without a
"the buck stops here" PTL position.  And not every question is answered - for
example, who looks for potential cores to mentor and bring up to speed while
still ensuring diversity in the core group over time?  Look forward to a
governance proposal in the coming month or so about this topic, and hopefully a
lively discussion that will help us sort out the rough edges!

2.) There has been an increasing consensus that the division between the
Technical Committee and the User Committee of OpenStack is an artificial one, a
relic of the rapid-expansion phase of the OpenStack universe and not in keeping
with the current OpenStack environment.  In particular, with more operators
contributing back and interested in guiding the technical evolution of
OpenStack, the dichotomy between developers and operators/users seems false and
sends the wrong message.  To that end, the TC has formally proposed that the TC
and UC should merge into a single body.  Because changes to the Foundation
bylaws are costly and slow, we would like to execute this merger without changes
to the foundation bylaws.  Since the TC is specified in greater detail
than the UC in the bylaws, the merger would be accomplished by the UC becoming a
subset of the TC.  This change was anticipated by the higher rate of operators
being nominated and elected to the TC this past election, and the proposed
governance change [1] completes a merger that has been a long time in coming.

3.) There has been some feedback from operators that the unfinished migration
from project-specific clients to the unified OpenStack client causes uncertainty
and difficulty for both operators and users.  Some have even created their own
client that hides the difference between the unified client and the remaining
project-specific clients.  This is obviously a bad experience and something we
can improve.  Given this, the TC will place a greater emphasis on preparing the
community to conclude the migration to OSC.

4.) The community goals for the V cycle have been selected, and they are to
conclude the migration to Zuul v3, and to migrate the base Ubuntu image used in
the upstream gates from Bionic 18.04 to Focal 20.04 [2].  

5.) In the U cycle the TC created the 'ideas' repository [3], which is a place
for people to post ideas that they think would be great for the OpenStack
community.  We did this after reflecting that there are a lot of great ideas
that are discussed on the mailing list that are perhaps a bit ahead of their
time, and then get lost in the mailing list archives.  Rather than forgetting
about an idea, it could be posted to the ideas repo and then brought back when
time is right.  Rather than shifting the graveyard for ideas from the mailing
list to this repo, the TC or a representative could review the tabulated ideas
with an eye to what is ready for revival and discussion in a PTG or forum
session.

--- Neutron ---

The Neutron community made good use of the Jitsi/Meetpad platform after a few
opening hiccups.  It handled the large number of people in the room well for the
most part, and the etherpad integration was interesting.  I think it was great
how the Neutron team worked well with the Keystone, Nova, Cyborg, and Edge SIG
teams and had great collaboration on each front.  The themes in the Neutron
community were the same as they have been before: stadium projects are
increasingly being run by the Neutron core team, those that are not are entering
hibernation, with networking-midonet currently at the most risk.  The community
slowly pushes forward with Engine Facade and is looking to fully deprecate
python-neutronclient.  We acknowledged that the neutron-lib migration has
stalled and decided to make the process easier with debtcollector deprecations.  

The biggest thing for me in the summit was the decision to move forward with
ML2/OVN as the default back end for Neutron, including in devstack.  This will
be proposed to the broader community and the Neutron team will work with
everyone to make sure this is a success.

In conclusion, I am as always grateful for the tremendous worldwide OpenStack
community.  I am proud of how much was accomplished, and I think this PTG sets
the stage for a great Victoria cycle.

Thanks,

Nate

[1] https://review.opendev.org/#/c/734074/
[2] Waiting on https://review.opendev.org/#/c/731213/ to be merged
[3] https://governance.openstack.org/ideas/