Open Stack

+1


On Sat, Sep 21, 2013 at 1:15 AM, Ravi Chunduru <ravivsn at gmail.com> wrote:

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


-- 
Shake Chen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130921/af1ed87b/attachment.html>