<div dir="ltr">Folks, <div><br></div><div>This thread has gotten too long and hard to follow. </div><div>It is clear that we should discuss/address this. </div><div>My suggestion is that we organize a session in Atlanta PTG meeting and discuss this.</div><div><br></div><div>I am going to add this on the Neutron etherpad - should this be included in any other session as well? </div><div><br></div><div>-Sukhdev</div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 24, 2017 at 12:33 AM, Ihar Hrachyshka <span dir="ltr"><<a href="mailto:ihrachys@redhat.com" target="_blank">ihrachys@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi team,<br>
<br>
I would like to propose my PTL candidacy for Pike.<br>
<br>
Some of you already know me. If not, here is my brief OpenStack bio. I<br>
joined the community back in Havana, and managed to stick around till<br>
now. During the time, I fit several project roles like serving as a<br>
Neutron liaison of different kinds (stable, oslo, release), fulfilling<br>
my Neutron core reviewer duties, taking part in delivering some<br>
longstanding features, leading QoS and upgrades subteams, as well as<br>
being part of Neutron Drivers team. I also took part in miscellaneous<br>
cross project efforts.<br>
<br>
I think my experience gives me broad perspective on how the OpenStack<br>
community and more specifically Networking works, and what is expected<br>
from its PTL.<br>
<br>
First, let me describe my vision of PTL role.<br>
<br>
* It's not only about technical intricacies. It's also about people<br>
and procedures that make the project run smoothly day by day. The role<br>
of PTL is in empowering other team members, keeping track of any<br>
roadblocks and inconveniences that the team have, and working on<br>
streamlining workflow.<br>
<br>
* It's about delegation. We should make it a habit to look at the list<br>
of potential candidates for core membership and other leadership and<br>
administrative positions not just in times we are short on existing<br>
members.<br>
<br>
* PTL should be transparent and replaceable. I will work with outgoing<br>
PTL to capture oral wisdom and state of affairs into a publicly<br>
accessible project dashboard, and I will continue sharing such<br>
information with the team on constant basis. The project dashboard<br>
will give you answers to questions like: what's the project direction?<br>
what are current priorities, and where does each stand? what's on PTL<br>
and Drivers' mind? which cross-project and governance initiatives are<br>
currently worked on? etc.<br>
<br>
As PTL, I'd like to focus on the following things:<br>
<br>
* Speed up the RFE/spec process. We should manage RFE/spec review<br>
pipeline in such a way so that initiatives that are given a green<br>
light on writing up design details get timely feedback and can get<br>
past spec process in reasonable time. At the same time we should be<br>
honest to the community not to accept proposals that have high risk to<br>
fall through cracks due to lack of manpower. I will encourage usage of<br>
reviewday and other tools to keep focus of the team. We will mull over<br>
the idea of virtual code sprints for high demand topics.<br>
<br>
* Continue Stadium program without drastic changes of direction.<br>
Thanks to Armando, we filled the Stadium with tangible meaning. I want<br>
us to build on top of that foundation to drive consistency and high<br>
quality standards between participating projects.<br>
<br>
* Support Marketplace rework. With huge number of drivers and plugins<br>
available for Neutron, it became hard for operators to pick the right<br>
one and for vendors to advertise their features. There is strong<br>
vendor interest to improve situation there. We should boost Feature<br>
Classification work, and integrate it with how third party CI systems<br>
report test results so that they become useful for Marketplace.<br>
<br>
* Introduce Gate Keeper role. We've recently made significant progress<br>
in how we deal with gate: we expanded coverage to new types of jobs,<br>
we utilize Grafana and other community tools, we review gate-failure<br>
tagged bugs during weekly meetings. Sadly, sometimes gate becomes<br>
unstable, and it slows down work progress for everyone. In such<br>
cases, it's all about timely addressing the issue. For that matter, I<br>
will work with the team on defining a new Gate Keeper role that would<br>
help prioritizing current gate issues, as well as proactively work<br>
with the team on gate instability vectors. I believe clear ownership<br>
is the key.<br>
<br>
* Make centralized L3 legacy indeed. We have DVR and HA in tree for<br>
quite some time. Both technologies are now mature enough, and are no<br>
longer mutually exclusive. Sadly, they are still second class citizens<br>
in our own gate. My belief is we should give users a clear signal<br>
that old L3 is indeed legacy by switching our jobs to DVR+HA where<br>
applicable. I am sure that will surface some previously unknown<br>
issues, but we'll be ready to tackle them. While it's never black or<br>
white, I suggest we prioritize this work over adding new major L3<br>
features.<br>
<br>
* Support existing maintenance initiatives. I'd like us to close<br>
neutron-lib saga in Pike, and consider neutron-lib switch for a<br>
requirement to all Stadium projects starting from Queens. We should<br>
also close OSC transition during Pike.<br>
<br>
* Explore alternative ways to evolve Neutron API. Piling up<br>
extensions and allowing third parties to completely change core<br>
resource behaviour is not ideal, and now that api-ref and API<br>
consolidation effort in neutron-lib are closer to completion, we may<br>
have better answers to outstanding questions than during previous<br>
attempts to crack the nut. I would like to restart the discussion some<br>
time during Pike.<br>
<br>
Now, you may ask, it's a nice list of things to do, but we can't<br>
manage to handle all of that in one cycle, can we? Well, some of those<br>
bullet points are procedural (RFE process tweaks, next Stadium steps,<br>
Gate Keeper role) and, with team support, won't take too much time to<br>
adopt (yes I am an optimist...), and hopefully will deliver the fruits<br>
in the same cycle.<br>
<br>
As for technical bits, it's mostly ongoing work, and I am sure we will<br>
still have time for other work that our bright contributors tend to<br>
deliver. Also, it's in everyone's interest to get gate into better<br>
shape,<br>
<br>
Of course, some of the goals are long stretching and may spill over<br>
into next cycles. It's ok as long as we agree on the path. Do we?<br>
<br>
Thanks for attention,<br>
Ihar<br>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
</blockquote></div><br></div>