[openstack-dev] [Nova] Things to tackle in Liberty

Michael Still mikal at stillhq.com
Wed Apr 8 21:07:24 UTC 2015


I just wanted to send a note about John running in the PTL election for Nova.

I want to make it clear that I think having more than one candidate is
a good thing -- its a healthy part of a functional democracy, and it
also means regardless of the outcome we have at least one succession
planning option should a PTL need to step down at some point in the
future.

That said, I think there are a few things we need to do in Liberty,
regardless of who is PTL. I started this as a Google doc to share with
John if he won so that we didn’t drop the ball, but then I realised
that nothing here is secret. So, here is my brain dump of things we
need to do in Liberty, in no particular order:

nova-coresec reboot
================

The nova-coresec team has been struggling recently to keep up with
their workload. We need to drop people off this team who haven’t had
time recently to work on security bugs, and we need to find new people
to volunteer for this team, noting that the team is kept deliberately
small because of embargoed security vulnerabilities. If I am not
re-elected as PTL, I will probably volunteer for this team.

priorities and specs
===============

I think the current spec process is starting to work well for us, and
that priorities was a success. We should continue with specs, but with
an attempt to analyse why so many approved specs don’t land (we have
had about 50% of our approved specs not land in Juno and Kilo). Is
that as simple as code review bandwidth? Or is the problem more
complicated than that? We just don’t know until someone goes digging.

Priorities worked well. We need to start talking about what should be
a priority in Liberty now, and the first step is to decide as a team
what we think the big problems we’re trying to solve in Liberty are.

nova-core
========

I think there are a couple of things to be done here.

There are still a few idle cores, particularly people who haven’t done
less than ten reviews in the last 90 days. We should drop those people
from core and thank them for their work in the past noting once again
that this is a natural part of the Open Source process -- those people
are off working on other problems now and that’s cool.

We also need to come up with a way to grow more cores. Passive
approaches like asking existing cores to keep an eye out for talent
they trust haven’t worked, so I think its time to actively start
mentoring core candidates.

I am not convinced that just adding cores will solve our review
bandwidth problems though. We have these conversations about why
people’s reviews sit around without a lot of data to back them up, and
I feel like we often jump to conclusions that feel intuitive but that
aren’t supported by the data.

nova-net
=======

OMG, this is still a thing. We need to actually work out what we’re
doing here, and then do it. The path isn’t particularly clear to me
any more, I thought I understood what we needed to do in Kilo, but it
turns out that operators don’t feel that plan meets their needs.
Somehow we need to get this work done. This is an obvious candidate
for a summit session, if we can come up with a concrete proposal to
discuss.

bugs
====

Trivial bug monkey’ing has worked well for us in Kilo, but one of our
monkeys is off running as a PTL. We need to ensure we have this
staffed with people who understand the constraints on the bugs we’re
willing to let through this process. It would be sad to see this die
on the vine.

We also need to fix more bugs. I know we always say this, but we don’t
have enough senior developers just kicking around looking at bugs to
fix in a systematic way. This is something I used to do when I had
more time before PTL’ing became a thing. If I am not elected this is
the other thing I’ll probably go back to spending time on.

conclusion
========

I make no claim that my list is exhaustive. What else do you think we
should be tackling in Liberty?

Michael

-- 
Rackspace Australia



More information about the OpenStack-dev mailing list