Juno TC Candidacy

Share

Another email archived for historical reasons.

I'd also like to announce my TC candidacy. I am currently a member of
the TC, and I would like to continue to serve.

I first started hacking on Nova during the Diablo release, with my
first code contributions appearing in the Essex release. Since then
I've hacked mostly on Nova and Oslo, although I have also contributed
to many other projects as my travels have required. For example, I've
tried hard to keep various projects in sync with their imports of
parts of Oslo I maintain.

I work full time on OpenStack at Rackspace, leading a team of
developers who work solely on upstream open source OpenStack. I am a
Nova and Oslo core reviewer and the Nova PTL.

I have been serving on the TC for the last year, and in the Icehouse
release started acting as the liaison for the board "defcore"
committee along with Anne Gentle. "defcore" is the board effort to
define what parts of OpenStack we require vendors to ship in order to
be able to use the OpenStack trade mark, so it involves both the board
and the TC. That liaison relationship is very new and only starting to
be effective now, so I'd like to keep working on that if you're
willing to allow it.
Share

Juno Nova PTL Candidacy

Share

This is a repost of an email to the openstack-dev list, which is mostly here for historical reasons.

Hi.

I would like to run for the OpenStack Compute PTL position as well.

I have been an active nova developer since late 2011, and have been a
core reviewer for quite a while. I am currently serving on the
Technical Committee, where I have recently been spending my time
liaising with the board about how to define what software should be
able to use the OpenStack trade mark. I've also served on the
vulnerability management team, and as nova bug czar in the past.

I have extensive experience running Open Source community groups,
having served on the TC, been the Director for linux.conf.au 2013, as
well as serving on the boards of various community groups over the
years.

In Icehouse I hired a team of nine software engineers who are all
working 100% on OpenStack at Rackspace Australia, developed and
deployed the turbo hipster third party CI system along with Joshua
Hesketh, as well as writing nova code. I recognize that if I am
successful I will need to rearrange my work responsibilities, and my
management is supportive of that.

The future
--------------

To be honest, I've thought for a while that the PTL role in OpenStack
is poorly named. Specifically, its the T that bothers me. Sure, we
need strong technical direction for our programs, but putting it in
the title raises technical direction above the other aspects of the
job. Compute at the moment is in an interesting position -- we're
actually pretty good on technical direction and we're doing
interesting things. What we're not doing well on is the social aspects
of the PTL role.

When I first started hacking on nova I came from an operations
background where I hadn't written open source code in quite a while. I
feel like I'm reasonably smart, but nova was certainly the largest
python project I'd ever seen. I submitted my first patch, and it was
rejected -- as it should have been. However, Vishy then took the time
to sit down with me and chat about what needed to change, and how to
improve the patch. That's really why I'm still involved with
OpenStack, Vishy took an interest and was always happy to chat. I'm
told by others that they have had similar experiences.

I think that's what compute is lacking at the moment. For the last few
cycles we're focused on the technical, and now the social aspects are
our biggest problem. I think this is a pendulum, and perhaps in a
release or two we'll swing back to needing to re-emphasise on
technical aspects, but for now we're doing poorly on social things.
Some examples:

- we're not keeping up with code reviews because we're reviewing the
wrong things. We have a high volume of patches which are unlikely to
ever land, but we just reject them. So far in the Icehouse cycle we've
seen 2,334 patchsets proposed, of which we approved 1,233. Along the
way, we needed to review 11,747 revisions. We don't spend enough time
working with the proposers to improve the quality of their code so
that it will land. Specifically, whilst review comments in gerrit are
helpful, we need to identify up and coming contributors and help them
build a relationship with a mentor outside gerrit. We can reduce the
number of reviews we need to do by improving the quality of initial
proposals.

- we're not keeping up with bug triage, or worse actually closing
bugs. I think part of this is that people want to land their features,
but part of it is also that closing bugs is super frustrating at the
moment. It can take hours (or days) to replicate and then diagnose a
bug. You propose a fix, and then it takes weeks to get reviewed. I'd
like to see us tweak the code review process to prioritise bug fixes
over new features for the Juno cycle. We should still land features,
but we should obsessively track review latency for bug fixes. Compute
fails if we're not producing reliable production grade code.

- I'd like to see us focus more on consensus building. We're a team
after all, and when we argue about solely the technical aspects of a
problem we ignore the fact that we're teaching the people involved a
behaviour that will continue on. Ultimately if we're not a welcoming
project that people want to code on, we'll run out of developers. I
personally want to be working on compute in five years, and I want the
compute of the future to be a vibrant, friendly, supportive place. We
get there by modelling the behaviour we want to see in the future.

So, some specific actions I think we should take:

- when we reject a review from a relatively new contributor, we should
try and pair them up with a more experienced developer to get some
coaching. That experienced dev should take point on code reviews for
the new person so that they receive low-latency feedback as they
learn. Once the experienced dev is ok with a review, nova-core can
pile on to actually get the code approved. This will reduce the
workload for nova-core (we're only reviewing things which are of a
known good standard), while improving the experience for new
contributors.

- we should obsessively track review performance for bug fixes, and
prioritise them where possible. Let's not ignore features, but let's
agree that each core should spend at least 50% of their review time
reviewing bug fixes.

- we should work on consensus building, and tracking the progress of
large blueprints. We should not wait until the end of the cycle to
re-assess the v3 API and discover we have concerns. We should be
talking about progress in the weekly meetings and making sure we're
all on the same page. Let's reduce the level of surprise. This also
flows into being clearer about the types of patches we don't want to
see proposed -- for example, if we think that patches that only change
whitespace are a bad idea, then let's document that somewhere so
people know before they put a lot of effort in.

Thanks for taking the time to read this email!
Share

Havana Nova PTL elections

Share

This is just a quick reminder that there are only a couple more days to vote in the Nova PTL elections for the Havana cycle. If you’re eligible to vote, you should have a voting URL in your email.

The candidates:

The incumbent PTL, Vishvananda Ishaya, has chosen not to run.

Rackspace is hiring OpenStack developers, let me know if you want to know more.

Share