[openstack-dev] [Nova] PTL Candidacy

John Garbutt john at johngarbutt.com
Wed Apr 8 18:25:10 UTC 2015


I am johnthetubaguy on IRC.

I would like to run for the OpenStack Compute (Nova) PTL position.

I currently work as a Principal Engineer at Rackspace, focusing on
software development for the Rackspace public cloud.


I started working with Nova in late 2010, working on a private cloud
style packaging of XenServer and OpenStack at Citrix. Later in 2010,
my efforts moved towards helping maintain the upstream XenServer
support. In early 2013 I moved to Rackspace to work on their public

Over the last few releases, I have been helping with some of the
release management, running some nova meetings, blueprint/specs
management and in various other Nova relating activities.

I would like to build on this experience and help continue Nova’s evolution.

Code Contributions

Its no secret that many contributors are finding it harder and harder
to get their code merged into Nova.

We need to ensure we maintain (ideally increase) code quality and
consistency, but we also need to scale out our processes. Its a hard
problem, but I am sure we can do better.

I support the idea of moving to a kind of “tick-tock” release for
Nova. Adopting this would mean Liberty has more room for new
‘features’, and the M release will have a similar focus on stability
to Kilo.

During Kilo, the focus on fixing bugs and working on fixing up some of
the technical debt we have accrued. That of course, meant there were
many features we were unable to merge, because we were focusing more
on other things.

There are some really promising ideas, and we need to start trying out
some of these solutions very soon. I think a key part of why its hard
to expand nova-core is because it currently means too much to be
dropped from nova-core. We need that group to be more fluid.


Not all process is good, but some can be helpful to communication
between such a large community.

We are now better at agreeing priorities for a release, and following
through on that. We are better at reviving, agreeing and documenting
plans for features in specs. We are now making better use of dev ref
to capture longer term work streams, and their aims.

More importantly, we relaxed a lot of the nova-spec process for
blueprints that don’t need that level of overhead.

When we focus our review effort, such as with the trivial patch list,
we have seen great results. I think we need to expand the groups of
reviews that need immediate attention to include reviews that a sub
group feels is now “ready”. As trust builds between the central team
and the sub group, we can look at how much that can evolve to a more
formal federated system, as the sub group gains trust. But I hope
better ideas will come along that we can consider and look at

The key thing, lets continue this evolution, so we can scale out the
community, keep the quality high, but while keeping everyone

Users and Operators

The API v2.1 effort is a great start on the road towards better
interoperability. This is a key step towards ensuring the compute API
looks and feels the same regardless of what Nova deployment you are
pointing at.

I feel we need to be more upfront about what is known to work, and
what is unknown. We started down this path for Hypervisor drivers, I
feel we need to revive this effort, and look at other combinations:

We can look at defining how well tested particular combinations are,
using a similar methodology to devcore. But the important thing is
having open information on what is known to work.

We are getting clear feedback from our users about some areas of the
code that need attention. We need to continue to be responsive to
those requests, and look at ways to improve that process.


This email has got too long and writing is not my strong point. But
for those who don’t know me, I hope it gives you a good idea about
where I stand on some of the key issues facing the Nova community.

Thanks for reading.


More information about the OpenStack-dev mailing list