[openstack-dev] [Nova] Candidacy for Compute (Nova) PTL
Anita Kuno
anteaya at anteaya.info
Fri Sep 20 17:51:24 UTC 2013
Please note that the +1's attached to the candidate announcement are not
considered votes.
Voting begins starting September 27th.
I can appreciate that folks want to demonstrate their support for their
candidate of choice.
Since we have 19 positions and I am expecting multiple candidate
announcements for each, I will ask that subsequent emailers of the +1
variety to express their support in other methods, including the
upcoming election.
I need to ensure I don't miss important email traffic.
My thanks in advance for your understanding,
Anita.
On 13-09-20 01:26 PM, Boris Pavlovic wrote:
> +1
>
>
> On Fri, Sep 20, 2013 at 9:21 PM, Shake Chen <shake.chen at gmail.com
> <mailto:shake.chen at gmail.com>> wrote:
>
> +1
>
>
> On Sat, Sep 21, 2013 at 1:15 AM, Ravi Chunduru <ravivsn at gmail.com
> <mailto:ravivsn at gmail.com>> wrote:
>
> +1
>
>
> On Fri, Sep 20, 2013 at 10:12 AM, Russell Bryant
> <rbryant at redhat.com <mailto: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
> <mailto: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
> <mailto:OpenStack-dev at lists.openstack.org>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> --
> Shake Chen
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> <mailto:OpenStack-dev at lists.openstack.org>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130920/4526bdd3/attachment.html>
More information about the OpenStack-dev
mailing list