Open Stack

+1


On Fri, Sep 20, 2013 at 10:12 AM, Russell Bryant <rbryant at redhat.com> wrote:

> 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
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Ravi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130920/6634c156/attachment.html>