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.c...@gmail.com
<mailto:shake.c...@gmail.com>> wrote:
+1
On Sat, Sep 21, 2013 at 1:15 AM, Ravi Chunduru <ravi...@gmail.com
<mailto:ravi...@gmail.com>> wrote:
+1
On Fri, Sep 20, 2013 at 10:12 AM, Russell Bryant
<rbry...@redhat.com <mailto:rbry...@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:rbry...@redhat.com,n,z
My reviews:
https://review.openstack.org/#/q/reviewer:rbry...@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@lists.openstack.org
<mailto:OpenStack-dev@lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Ravi
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
<mailto:OpenStack-dev@lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Shake Chen
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
<mailto:OpenStack-dev@lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
