[openstack-dev] [Neutron] PTL Candidacy
armamig at gmail.com
Wed Mar 16 17:34:47 UTC 2016
I would like to propose my candidacy for the Neutron PTL.
I have been the Neutron PTL for the Mitaka release, and I would like to
continue the journey on which I have embarked upon a little over six months
Back then, I had a number of objectives which I wanted to achieve with the
help of the Neutron team, and with this candidacy statement I would like to
take the opportunity to look back and see what we have accomplished and
what else is waiting ahead of us:
- Stability is the priority: I have introduced a rotation mechanism for
triaging and staying on top of bugs; with that, we have a very little
percentage of bugs that go unacknowledged, and even though we only managed
to fix only 60% of all bugs reported in the Mitaka timeframe, some might
regard this as a remarkable achievement. I also made sure the Neutron
projects was amongst the most stable one, by aggressively addressing
intermittent failures, and by ensuring that failures did not impact the
integrated gate. As of today, the success rate for Neutron (alone) is at
>98%. We also worked hard to extend test coverage to DVR, Linuxbridge and
Grenade multinode. Going forward, I'd like to focus on improving the
stability of multinode jobs, and look at how we can do more reliable and
exhaustive performance testing on a more regular basis.
- Narrow the focus: we all know by now my attempt to address the needs
and the issues of the Stadium, and the team effort aimed at standing up
neutron-lib to allow for Neutron projects to loosely couple together. The
journey is far from being over and I will continue to work towards a
resolution that strikes a good compromise for everybody. On the other end,
I worked hard with the rest of the drivers team members to ensure a
coherent strategy and vision when assessing and approving RFE's. I proposed
process changes to ensure that reviewers and contributors can be more
focussed and work together towards a well defined goal.
- Consistency is paramount: promoting the documentation of our practices
(like our deputy, blueprint/rfe guidelines and release postmortem), as well
as starting the 'Effective Neutron' guide have been two key areas that
allowed our developers to have a common understanding on how we operate,
review, develop and manage our project. More needs to be done to ensure we
become 'more predictable' in terms of the software we produce and the
quality associated with it, including end-user facing documentation.
- Define long term strategy: when I started looking at this area,
Neutron had 400+ blueprints targeted. I tried to put some sanity back into
the feature submission process by limiting who can actually submit feature
proposals (the drivers team) and by cleaning up the huge backlog of
blueprints we had (currently we have 15 blueprints and 19 RFEs). That said
this is an area where I feel I have not made enough of a dent to be
satisfied. This is somewhat tangential to the needs of the Stadium, but I
think we need more time to execute a plan of action that can yield positive
- Keep developers and reviewers _aware_: I worked relentlessly to remind
our reviewers to stay focussed and review what matters for a given release.
I think we have achieved this with mixed success, and I know that some of
us worked hard to give us the tools to help us stay more aware.
- I would like to promote a 'you merge it, you own it' type of
mentality: this is typically done by leading by example, and I am pleased
to see that many of us take great pride in the code they review and merge.
We need to continue to promote this attitude.
And last but not least:
- Improve the relationships with other projects: Nova and QA primarily.
I personally feel that we went a long way to improve these relationships,
from the technical front (for example by improving the provisioning
workflow of networking resources for Nova instances - aka get-me-a-network,
and by tackling the testing issues affecting Neutron) to the the social
front, by having a good representation of contributors across multiple
projects at the various mid-cycle events. There is always room for
improvement, of course!
If you liked what I did/said, then allow me to continue.
Thanks for reading and, as usual, forgive the typos!
Armando Migliaccio (aka armax)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev