[openstack-dev] [Nova] Nova PTL candidacy

Monty Taylor mordred at inaugust.com
Thu Mar 7 01:02:30 UTC 2013


I confirm that Michael is eligible for to be a PTL cadidate for Nova.

On 03/06/2013 07:55 PM, Michael Still wrote:
> Heya,
> 
> I would also like to run for the Nova PTL position. Let me start out
> by saying that Russell has my complete confidence and would do a
> fantastic job as a PTL. However, I think its a little unhealthy that
> we keep having elections with only one candidate and I'd like to see
> us develop a culture of healthy elections. I would say that I think
> regardless of who wins I'd like to see more delegation in the Nova PTL
> role, which will make the job easier and more enjoyable.
> 
> *** Who am I? ***
> 
> I am a senior software developer at Rackspace Hosting. Before that I
> was a operations engineer at Canonical, and before that a Site
> Reliability Engineer at Google. I've been working in "cloud" in some
> form or other since before it had a name.
> 
> I have been working on Nova since late 2011, mostly focussed on the
> libvirt hypervisor driver. I am also an Oslo core reviewer and serve
> on the OpenStack Vulnerability Management Team. I am a frequent code
> reviewer, and have contributed a significant body of code to Nova over
> the last year. I've focussed mostly on Nova because I think its an
> interesting set of problems, but also because I think its the way
> compute in general will be managed in the future -- for example if we
> all end up with racks of 3,000 ARM machines, I'd like us to live in a
> world where that is managed by something like the baremetal
> hypervisor.
> 
> I was also the Director for linux.conf.au 2013, which is the largest
> event covering OpenStack to be held in Australia so far. I mention
> this because I feel the experience is relevant to Nova in that the
> conference is run with an entirely volunteer staff. There are strong
> parallels between managing a hundred volunteers for a two year long
> project and being Nova PTL and I think I've learnt some things about
> running volunteer teams that can be applied to Nova. Specifically I'd
> like to see more delegation occur. This doesn't have to be super
> formal -- I'm thinking more along the lines of someone leading the bug
> triage effort or ensuring code reviews happen in a timely manner.
> 
> I also have the support of my employer, who has said that they will
> allow me the time required for this role, for which I thank them.
> 
> *** Platform ***
> 
> I think there are a few key things that the Nova team needs to focus
> on in the next release or two. These are the things which will define
> us as more people deploy OpenStack and have their first formative
> experiences. We need to work hard to make sure that those experiences
> are positive ones, because its much harder to fix a poor first
> impression later.
> 
> * We need to be better about onboarding new developers to the project.
> Our processes are complicated and somewhat poorly documented. To this
> end I've proposed a session at the Portland OpenStack conference about
> how to get up to speed as an OpenStack developer, but with a specific
> focus on Nova. Regardless of what happens with this election or the
> selection process for talks at the conference, I intend to vigorously
> pursue helping new developers get up to speed on how to contribute to
> Nova.
> 
> * We've done a great job of adding features of Nova, but now is the
> time to burn down our bug backlog (over 500 bugs!), and get better a
> triaging bugs in a timely manner. Similarly, we also need to be better
> at getting a first review on new submissions -- its a pretty bad
> experience when your first patch sits around for days waiting for its
> first review. We can do much of that by providing more visibility into
> how we're doing with those things so they don't get forgotten. I'd
> like to see these issues consistently reported on at weekly Nova
> meetings, and I'd like the community to start talking about more
> complicated "who contributed to Nova" metrics than just lines of code.
> I've done some early work on what some of these metrics would look
> like, and you can see the results at
> http://openstack.stillhq.com/reviews/report.html
> 
> * We need to take security more seriously. Often security
> vulnerabilities sit for too long waiting for review from core. I will
> acknowledge that I'm as much of the problem there as anyone, but we
> need to focus on getting better at that. To that end, I'd also like to
> see a more systematic effort to find security problems before they are
> discovered by our users, and I'd like to see the Foundation help out
> here with some security consulting if we can't find the resources we
> need within the community.
> 
> * I think its clear that OpenStack is a great choice for public
> clouds. We need to be working hard to make sure that our
> implementation decisions work well for smaller private clouds as well.
> OpenStack should ship with sensible defaults, and work well with
> default configuration. Things are ok at the moment, but there is more
> we can do to make this easier for our users -- for example HA is quite
> hard to configure at the moment and can be made easier.
> 
> * Finally, I think the PTL needs to delegate more. The PTL doesn't
> have to be trying to triage all bugs him or herself. They don't even
> need to be driving the meetings for that matter. They should have a
> trusted team of passionate assistants to help with the role. Its clear
> we have team members who are passionate about different aspects of
> making Nova great, and we should encourage that as much as possible.
> 
> *** Conclusion ***
> 
> To steal a little from Russell I'd also like to thank Vish for his
> efforts. If it wasn't for his patient mentoring when I first joined
> the project I probably would have walked away. Instead, I'm left with
> a deep attachment to Nova and the community which runs it. I'd also
> like to thank Russell for running. Its hard to put yourself out there
> and run for something like this.
> 
> Thanks,
> Michael
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 



More information about the OpenStack-dev mailing list