Open Stack

Greetings,

I would like to run for the OpenStack Compute (Nova) PTL position.

I am the current Nova PTL.  I have been working on OpenStack since late
2011 and have been primarily been focused on Nova since then.  I would
love to continue in this position to help drive the Nova project
forward.

Quite a bit of work goes into the PTL position beyond specific technical
work:

    https://wiki.openstack.org/wiki/PTLguide

Most of what I will focus on in this message are the things that I have
done and would like to do that go beyond technical topics.


* Havana

The Havana release is the first release where I served as the Nova PTL.
I feel that Havana has been a successful development cycle for us so
far.  You can find record of our progress toward the Havana release on
each of the milestone pages:

    https://launchpad.net/nova/+milestone/havana-1
    https://launchpad.net/nova/+milestone/havana-2
    https://launchpad.net/nova/+milestone/havana-3
    https://launchpad.net/nova/+milestone/havana-rc1

As the PTL, I led the creation of the design summit schedule for the
Nova track, as well as the majority of the blueprint handling for the
release roadmap.

For Icehouse, I expect this process to be largely the same, but I would
like to involve more people in prioritizing design summit sessions, as
well as reviewing blueprints.


* Code Review Process

The PTL of Nova is certainly not the only technical leader in
the project.  There is a team of technical leaders, the nova-core team,
responsible for processing the high volume of code review requests we
receive.  A key responsibility of the Nova PTL is to ensure that the
nova-core team has the right people on it at the right time.

To that end, I have started doing some things in the last release cycle
to help with managing the core team.  The first is starting to document
core team expectations:

    https://wiki.openstack.org/wiki/Nova/CoreTeam

The second is gathering metrics around the core activity of the team:
code reviews:

    http://russellbryant.net/openstack-stats/nova-reviewers-30.txt
    http://russellbryant.net/openstack-stats/nova-reviewers-90.txt
    http://russellbryant.net/openstack-stats/nova-reviewers-180.txt

The Nova project has seen an ongoing increase in contributions.  As a
result, there have been some complaints about review times.  It has been
a priority of mine to get a handle on this from a project management
perspective.  The first step here was to start collecting metrics on
review times, which you can find here:

    http://russellbryant.net/openstack-stats/nova-openreviews.html

Using these metrics, I can also compare how the Nova project's review
team is doing compared to other OpenStack projects.

    http://russellbryant.net/openstack-stats/all-openreviews.html

Now that we have this information, we have been able to set goals and
make changes based on real data.

You can find the code for generating all of these stats here:

    http://git.openstack.org/cgit/openstack-infra/reviewstats

As for the future, I think there are some obvious improvements that
could be made.  The biggest is that I think there is room to add more
people to the review team when the opportunity presents itself.  I would
also like to have another discussion about the future of compute
drivers, and whether maintainers of some drivers would rather have their
own repository.  I expect to have a design summit session on this topic:

    http://summit.openstack.org/cfp/details/4


* Sub-project Leadership

One thing that is very apparent to me is that given the Nova project's
size, I think there are too many things for one person to carry.  There
are multiple great people in the Nova community that step up regularly
to make things happen.  I think we should start looking at creating some
official sub-project leadership roles.  Here are some ideas with some
potential responsibilities:

 - python-novaclient lead
   - have a vision for python-novaclient
   - review all novaclient patches
   - ensure that novaclient blueprints get reviewed and bugs are triaged
   - build and lead a group of people interested in novaclient

 - nova bug triage lead
   - ensure bugs are triaged
   - ensure the highest priority bugs are discussed, either on the
     mailing list or in the weekly nova meeting
   - generate metrics on nova bugs
   - set goals for nova bug processing, and track our progress against
     the goals using the generated metrics
   - build and lead a group of people interested in helping nova by
     doing bug triage

 - nova-drivers team
   - (This actually already exists, but I think we could formalize
     responsibilities and make more use of it)
   - responsible for reviewing nova blueprints
   - ensure all blueprints have appropriate design documentation and fit
     within the overall project vision
   - regularly discuss blueprints with each other and the overall nova
     community via the mailing list and weekly meeting to ensure Nova
     has an accurate and high quality roadmap

These positions could either be elected by the technical contributors to
the Compute program (we sure love elections around here), or they could
simply be appointed by the PTL (my preference, I think).


* What do you think?

Finally, I would like to know what you all think.  What does the project
need to improve on?

What could I improve on if I were to be re-elected as the PTL?


* Technical Matters

I've used most of this message to focus on non-technical matters.  That
certainly does not mean that I do not have strong opinions on the
technical future of Nova.  In fact, I feel strongly that we need to
continue to invest heavily in these areas:

   1) Upgrades
   2) Scale
   3) Security

Upgrades - We have made ongoing progress towards supporting live rolling
upgrades over the last few releases.  We need to continue to push hard
on this.

    http://summit.openstack.org/cfp/details/94

Scale - Nova is already being deployed at very large scale (10s of
thousands of nodes).  However, there are definitely pain points.  I'd
like to see more people working on cells support.  Even within a cell
there are things we could improve.  For example, I'd like to see more
progress toward supporting more scalable messaging, either by adding
support for AMQP 1.0 which supports peer-to-peer messaging as well as
brokered, or by continuing to enhance the existing ZeroMQ support.
Enhancements to our database usage to make it more scalable are
important, as well.

Security - This is a priority for anyone deploying OpenStack, but
especially in a public setting.  One area we have had in our sights for
a while is the use of trusted messaging.  The infrastructure for this
should be merged early Icehouse, so I'd like to see Nova adopt it and
start making use of it as soon as possible.


* Other References

  My patches:
    https://review.openstack.org/#/q/owner:rbryant@redhat.com,n,z

  My reviews:
    https://review.openstack.org/#/q/reviewer:rbryant@redhat.com,n,z

  Activity Board:

http://activity.openstack.org/data/display/OPNSTK2/Technical+Contributors
    http://activity.openstack.org/data/pages/viewpage.action?pageId=3670022

  Ohloh profile:
    https://www.ohloh.net/accounts/russellb


***

I have had a blast working on OpenStack.  It is truly an honor to work
with so many talented people and to have been elected to help lead the
effort.

Thank you for your consideration,

-- 
Russell Bryant