<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Please note that the +1's attached to
the candidate announcement are not considered votes.<br>
<br>
Voting begins starting September 27th.<br>
<br>
I can appreciate that folks want to demonstrate their support for
their candidate of choice.<br>
<br>
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.<br>
<br>
I need to ensure I don't miss important email traffic.<br>
<br>
My thanks in advance for your understanding,<br>
Anita.<br>
<br>
On 13-09-20 01:26 PM, Boris Pavlovic wrote:<br>
</div>
<blockquote
cite="mid:CAD85om1jfMShZ-zc50OYvc6-jU7g+tbO55i_YS2_nnwLG_3jHQ@mail.gmail.com"
type="cite">
<div dir="ltr">+1</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Fri, Sep 20, 2013 at 9:21 PM, Shake
Chen <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:shake.chen@gmail.com" target="_blank">shake.chen@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">+1<br>
</div>
<div class="gmail_extra">
<div>
<div class="h5"><br>
<br>
<div class="gmail_quote">On Sat, Sep 21, 2013 at 1:15
AM, Ravi Chunduru <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:ravivsn@gmail.com" target="_blank">ravivsn@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">+1 </div>
<div class="gmail_extra">
<div>
<div><br>
<br>
<div class="gmail_quote">On Fri, Sep 20,
2013 at 10:12 AM, Russell Bryant <span
dir="ltr"><<a moz-do-not-send="true"
href="mailto:rbryant@redhat.com"
target="_blank">rbryant@redhat.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote"
style="margin:0 0 0 .8ex;border-left:1px
#ccc solid;padding-left:1ex">Greetings,<br>
<br>
I would like to run for the OpenStack
Compute (Nova) PTL position.<br>
<br>
I am the current Nova PTL. I have been
working on OpenStack since late<br>
2011 and have been primarily been
focused on Nova since then. I would<br>
love to continue in this position to
help drive the Nova project<br>
forward.<br>
<br>
Quite a bit of work goes into the PTL
position beyond specific technical<br>
work:<br>
<br>
<a moz-do-not-send="true"
href="https://wiki.openstack.org/wiki/PTLguide"
target="_blank">https://wiki.openstack.org/wiki/PTLguide</a><br>
<br>
Most of what I will focus on in this
message are the things that I have<br>
done and would like to do that go beyond
technical topics.<br>
<br>
<br>
* Havana<br>
<br>
The Havana release is the first release
where I served as the Nova PTL.<br>
I feel that Havana has been a successful
development cycle for us so<br>
far. You can find record of our
progress toward the Havana release on<br>
each of the milestone pages:<br>
<br>
<a moz-do-not-send="true"
href="https://launchpad.net/nova/+milestone/havana-1"
target="_blank">https://launchpad.net/nova/+milestone/havana-1</a><br>
<a moz-do-not-send="true"
href="https://launchpad.net/nova/+milestone/havana-2"
target="_blank">https://launchpad.net/nova/+milestone/havana-2</a><br>
<a moz-do-not-send="true"
href="https://launchpad.net/nova/+milestone/havana-3"
target="_blank">https://launchpad.net/nova/+milestone/havana-3</a><br>
<a moz-do-not-send="true"
href="https://launchpad.net/nova/+milestone/havana-rc1"
target="_blank">https://launchpad.net/nova/+milestone/havana-rc1</a><br>
<br>
As the PTL, I led the creation of the
design summit schedule for the<br>
Nova track, as well as the majority of
the blueprint handling for the<br>
release roadmap.<br>
<br>
For Icehouse, I expect this process to
be largely the same, but I would<br>
like to involve more people in
prioritizing design summit sessions, as<br>
well as reviewing blueprints.<br>
<br>
<br>
* Code Review Process<br>
<br>
The PTL of Nova is certainly not the
only technical leader in<br>
the project. There is a team of
technical leaders, the nova-core team,<br>
responsible for processing the high
volume of code review requests we<br>
receive. A key responsibility of the
Nova PTL is to ensure that the<br>
nova-core team has the right people on
it at the right time.<br>
<br>
To that end, I have started doing some
things in the last release cycle<br>
to help with managing the core team.
The first is starting to document<br>
core team expectations:<br>
<br>
<a moz-do-not-send="true"
href="https://wiki.openstack.org/wiki/Nova/CoreTeam"
target="_blank">https://wiki.openstack.org/wiki/Nova/CoreTeam</a><br>
<br>
The second is gathering metrics around
the core activity of the team:<br>
code reviews:<br>
<br>
<a moz-do-not-send="true"
href="http://russellbryant.net/openstack-stats/nova-reviewers-30.txt"
target="_blank">http://russellbryant.net/openstack-stats/nova-reviewers-30.txt</a><br>
<a moz-do-not-send="true"
href="http://russellbryant.net/openstack-stats/nova-reviewers-90.txt"
target="_blank">http://russellbryant.net/openstack-stats/nova-reviewers-90.txt</a><br>
<a moz-do-not-send="true"
href="http://russellbryant.net/openstack-stats/nova-reviewers-180.txt"
target="_blank">http://russellbryant.net/openstack-stats/nova-reviewers-180.txt</a><br>
<br>
The Nova project has seen an ongoing
increase in contributions. As a<br>
result, there have been some complaints
about review times. It has been<br>
a priority of mine to get a handle on
this from a project management<br>
perspective. The first step here was to
start collecting metrics on<br>
review times, which you can find here:<br>
<br>
<a moz-do-not-send="true"
href="http://russellbryant.net/openstack-stats/nova-openreviews.html"
target="_blank">http://russellbryant.net/openstack-stats/nova-openreviews.html</a><br>
<br>
Using these metrics, I can also compare
how the Nova project's review<br>
team is doing compared to other
OpenStack projects.<br>
<br>
<a moz-do-not-send="true"
href="http://russellbryant.net/openstack-stats/all-openreviews.html"
target="_blank">http://russellbryant.net/openstack-stats/all-openreviews.html</a><br>
<br>
Now that we have this information, we
have been able to set goals and<br>
make changes based on real data.<br>
<br>
You can find the code for generating all
of these stats here:<br>
<br>
<a moz-do-not-send="true"
href="http://git.openstack.org/cgit/openstack-infra/reviewstats"
target="_blank">http://git.openstack.org/cgit/openstack-infra/reviewstats</a><br>
<br>
As for the future, I think there are
some obvious improvements that<br>
could be made. The biggest is that I
think there is room to add more<br>
people to the review team when the
opportunity presents itself. I would<br>
also like to have another discussion
about the future of compute<br>
drivers, and whether maintainers of some
drivers would rather have their<br>
own repository. I expect to have a
design summit session on this topic:<br>
<br>
<a moz-do-not-send="true"
href="http://summit.openstack.org/cfp/details/4"
target="_blank">http://summit.openstack.org/cfp/details/4</a><br>
<br>
<br>
* Sub-project Leadership<br>
<br>
One thing that is very apparent to me is
that given the Nova project's<br>
size, I think there are too many things
for one person to carry. There<br>
are multiple great people in the Nova
community that step up regularly<br>
to make things happen. I think we
should start looking at creating some<br>
official sub-project leadership roles.
Here are some ideas with some<br>
potential responsibilities:<br>
<br>
- python-novaclient lead<br>
- have a vision for python-novaclient<br>
- review all novaclient patches<br>
- ensure that novaclient blueprints
get reviewed and bugs are triaged<br>
- build and lead a group of people
interested in novaclient<br>
<br>
- nova bug triage lead<br>
- ensure bugs are triaged<br>
- ensure the highest priority bugs
are discussed, either on the<br>
mailing list or in the weekly nova
meeting<br>
- generate metrics on nova bugs<br>
- set goals for nova bug processing,
and track our progress against<br>
the goals using the generated
metrics<br>
- build and lead a group of people
interested in helping nova by<br>
doing bug triage<br>
<br>
- nova-drivers team<br>
- (This actually already exists, but
I think we could formalize<br>
responsibilities and make more use
of it)<br>
- responsible for reviewing nova
blueprints<br>
- ensure all blueprints have
appropriate design documentation and fit<br>
within the overall project vision<br>
- regularly discuss blueprints with
each other and the overall nova<br>
community via the mailing list and
weekly meeting to ensure Nova<br>
has an accurate and high quality
roadmap<br>
<br>
These positions could either be elected
by the technical contributors to<br>
the Compute program (we sure love
elections around here), or they could<br>
simply be appointed by the PTL (my
preference, I think).<br>
<br>
<br>
* What do you think?<br>
<br>
Finally, I would like to know what you
all think. What does the project<br>
need to improve on?<br>
<br>
What could I improve on if I were to be
re-elected as the PTL?<br>
<br>
<br>
* Technical Matters<br>
<br>
I've used most of this message to focus
on non-technical matters. That<br>
certainly does not mean that I do not
have strong opinions on the<br>
technical future of Nova. In fact, I
feel strongly that we need to<br>
continue to invest heavily in these
areas:<br>
<br>
1) Upgrades<br>
2) Scale<br>
3) Security<br>
<br>
Upgrades - We have made ongoing progress
towards supporting live rolling<br>
upgrades over the last few releases. We
need to continue to push hard<br>
on this.<br>
<br>
<a moz-do-not-send="true"
href="http://summit.openstack.org/cfp/details/94"
target="_blank">http://summit.openstack.org/cfp/details/94</a><br>
<br>
Scale - Nova is already being deployed
at very large scale (10s of<br>
thousands of nodes). However, there are
definitely pain points. I'd<br>
like to see more people working on cells
support. Even within a cell<br>
there are things we could improve. For
example, I'd like to see more<br>
progress toward supporting more scalable
messaging, either by adding<br>
support for AMQP 1.0 which supports
peer-to-peer messaging as well as<br>
brokered, or by continuing to enhance
the existing ZeroMQ support.<br>
Enhancements to our database usage to
make it more scalable are<br>
important, as well.<br>
<br>
Security - This is a priority for anyone
deploying OpenStack, but<br>
especially in a public setting. One
area we have had in our sights for<br>
a while is the use of trusted messaging.
The infrastructure for this<br>
should be merged early Icehouse, so I'd
like to see Nova adopt it and<br>
start making use of it as soon as
possible.<br>
<br>
<br>
* Other References<br>
<br>
My patches:<br>
<a moz-do-not-send="true"
href="https://review.openstack.org/#/q/owner:rbryant@redhat.com,n,z"
target="_blank">https://review.openstack.org/#/q/owner:rbryant@redhat.com,n,z</a><br>
<br>
My reviews:<br>
<a moz-do-not-send="true"
href="https://review.openstack.org/#/q/reviewer:rbryant@redhat.com,n,z"
target="_blank">https://review.openstack.org/#/q/reviewer:rbryant@redhat.com,n,z</a><br>
<br>
Activity Board:<br>
<br>
<a moz-do-not-send="true"
href="http://activity.openstack.org/data/display/OPNSTK2/Technical+Contributors"
target="_blank">http://activity.openstack.org/data/display/OPNSTK2/Technical+Contributors</a><br>
<a moz-do-not-send="true"
href="http://activity.openstack.org/data/pages/viewpage.action?pageId=3670022"
target="_blank">http://activity.openstack.org/data/pages/viewpage.action?pageId=3670022</a><br>
<br>
Ohloh profile:<br>
<a moz-do-not-send="true"
href="https://www.ohloh.net/accounts/russellb"
target="_blank">https://www.ohloh.net/accounts/russellb</a><br>
<br>
<br>
***<br>
<br>
I have had a blast working on OpenStack.
It is truly an honor to work<br>
with so many talented people and to have
been elected to help lead the<br>
effort.<br>
<br>
Thank you for your consideration,<br>
<span><font color="#888888"><br>
--<br>
Russell Bryant<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a moz-do-not-send="true"
href="mailto:OpenStack-dev@lists.openstack.org"
target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a moz-do-not-send="true"
href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</font></span></blockquote>
</div>
<br>
<br clear="all">
<div><br>
</div>
</div>
</div>
<span><font color="#888888">-- <br>
Ravi<br>
</font></span></div>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a moz-do-not-send="true"
href="mailto:OpenStack-dev@lists.openstack.org"
target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a moz-do-not-send="true"
href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
</blockquote>
</div>
<br>
<br clear="all">
<br>
-- <br>
</div>
</div>
<span class="HOEnZb"><font color="#888888">Shake Chen<br>
<br>
</font></span></div>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a moz-do-not-send="true"
href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a moz-do-not-send="true"
href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
OpenStack-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>