[openstack-dev] [neutron] PTL candidacy

Ihar Hrachyshka ihrachys at redhat.com
Tue Jan 24 08:33:41 UTC 2017


Hi team,

I would like to propose my PTL candidacy for Pike.

Some of you already know me. If not, here is my brief OpenStack bio. I
joined the community back in Havana, and managed to stick around till
now. During the time, I fit several project roles like serving as a
Neutron liaison of different kinds (stable, oslo, release), fulfilling
my Neutron core reviewer duties, taking part in delivering some
longstanding features, leading QoS and upgrades subteams, as well as
being part of Neutron Drivers team. I also took part in miscellaneous
cross project efforts.

I think my experience gives me broad perspective on how the OpenStack
community and more specifically Networking works, and what is expected
from its PTL.

First, let me describe my vision of PTL role.

* It's not only about technical intricacies. It's also about people
and procedures that make the project run smoothly day by day. The role
of PTL is in empowering other team members, keeping track of any
roadblocks and inconveniences that the team have, and working on
streamlining workflow.

* It's about delegation. We should make it a habit to look at the list
of potential candidates for core membership and other leadership and
administrative positions not just in times we are short on existing
members.

* PTL should be transparent and replaceable. I will work with outgoing
PTL to capture oral wisdom and state of affairs into a publicly
accessible project dashboard, and I will continue sharing such
information with the team on constant basis. The project dashboard
will give you answers to questions like: what's the project direction?
what are current priorities, and where does each stand?  what's on PTL
and Drivers' mind? which cross-project and governance initiatives are
currently worked on? etc.

As PTL, I'd like to focus on the following things:

* Speed up the RFE/spec process. We should manage RFE/spec review
pipeline in such a way so that initiatives that are given a green
light on writing up design details get timely feedback and can get
past spec process in reasonable time.  At the same time we should be
honest to the community not to accept proposals that have high risk to
fall through cracks due to lack of manpower. I will encourage usage of
reviewday and other tools to keep focus of the team. We will mull over
the idea of virtual code sprints for high demand topics.

* Continue Stadium program without drastic changes of direction.
Thanks to Armando, we filled the Stadium with tangible meaning. I want
us to build on top of that foundation to drive consistency and high
quality standards between participating projects.

* Support Marketplace rework. With huge number of drivers and plugins
available for Neutron, it became hard for operators to pick the right
one and for vendors to advertise their features. There is strong
vendor interest to improve situation there. We should boost Feature
Classification work, and integrate it with how third party CI systems
report test results so that they become useful for Marketplace.

* Introduce Gate Keeper role. We've recently made significant progress
in how we deal with gate: we expanded coverage to new types of jobs,
we utilize Grafana and other community tools, we review gate-failure
tagged bugs during weekly meetings. Sadly, sometimes gate becomes
unstable, and it slows down work progress for everyone.  In such
cases, it's all about timely addressing the issue. For that matter, I
will work with the team on defining a new Gate Keeper role that would
help prioritizing current gate issues, as well as proactively work
with the team on gate instability vectors. I believe clear ownership
is the key.

* Make centralized L3 legacy indeed. We have DVR and HA in tree for
quite some time. Both technologies are now mature enough, and are no
longer mutually exclusive. Sadly, they are still second class citizens
in our own gate.  My belief is we should give users a clear signal
that old L3 is indeed legacy by switching our jobs to DVR+HA where
applicable.  I am sure that will surface some previously unknown
issues, but we'll be ready to tackle them.  While it's never black or
white, I suggest we prioritize this work over adding new major L3
features.

* Support existing maintenance initiatives. I'd like us to close
neutron-lib saga in Pike, and consider neutron-lib switch for a
requirement to all Stadium projects starting from Queens. We should
also close OSC transition during Pike.

* Explore alternative ways to evolve Neutron API.  Piling up
extensions and allowing third parties to completely change core
resource behaviour is not ideal, and now that api-ref and API
consolidation effort in neutron-lib are closer to completion, we may
have better answers to outstanding questions than during previous
attempts to crack the nut. I would like to restart the discussion some
time during Pike.

Now, you may ask, it's a nice list of things to do, but we can't
manage to handle all of that in one cycle, can we? Well, some of those
bullet points are procedural (RFE process tweaks, next Stadium steps,
Gate Keeper role) and, with team support, won't take too much time to
adopt (yes I am an optimist...), and hopefully will deliver the fruits
in the same cycle.

As for technical bits, it's mostly ongoing work, and I am sure we will
still have time for other work that our bright contributors tend to
deliver. Also, it's in everyone's interest to get gate into better
shape,

Of course, some of the goals are long stretching and may spill over
into next cycles. It's ok as long as we agree on the path. Do we?

Thanks for attention,
Ihar



More information about the OpenStack-dev mailing list