[openstack-dev] [Nova] PTL Candidacy

John Garbutt john at johngarbutt.com
Mon Mar 31 17:53:01 UTC 2014


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

I find it really rewarding to help resolve conflict. Gallup says I am
a: Learner, Arranger, Achiever, Relator, Includer. I like to listen to
all sides of the story, learn about everyones point of view, help
frame the argument, and help come up with a resolution that works for
everyone. That is why the idea of being a PTL excites me.

Nova excites me because I love projects that integrate lots of
different components into a single cohesive user experience. (I see it
as one of the upsides of my Dyslexia.)

Should I get elected, Rackspace has promised that Nova PTL will be my
full time job.

My (OpenStack) life story...

My first involvement with Nova was in late 2010, working on what
became Citrix's "Project Olympus" private cloud packaging of OpenStack
and XenServer. We got Nova, Glance, Swift and XenServer all installed
and configured from a CD (or optional PXE) install.

After some changes in direction at Citrix, I started focusing on
XenServer and OpenStack integration, with a particular focus on Nova.
This lead me to form the XenAPI sub team, and help Russell with his
formalisation of the "Nova Sub-Team" concept.

In early 2013, I moved to Rackspace. That allowed me to focus more
attention on the rest of Nova. I am part of the dev team working on
(probably) the largest Nova installation in the world, Rackspace Cloud
Servers. I quickly joined nova-core, and then nova-drivers. Most
recently taking up the role of blueprint czar.

I feel I am in a better position than most to understand the breadth
of the Nova community, given my varied experience:
* moved from packaging OpenStack, then contributing code to Nova, now
helping more with the leadership of Nova
* worked on packaging OpenStack for private clouds (at Citrix)
* currently helping run (probably) the largest Nova deployment on the
planet, at Rackspace
* worked at a company whose strategy is more focused on its own
product, than the success of OpenStack (at Citrix). Note: I consider
this a perfectly valid situation. Without people concentrating on
non-OpenStack projects and products, Nova would have nothing to

How I see the PTL role

The basics of the Project Team Lead (or Project Technical Lead) role
are covered here:

I feel that the role is really about fostering a vibrant community,
and ensuring decisions get made, not making the decisions. This
challenge really excites me, as in the past, I have had much fun, and
many successes, resolving conflicts between conflicting/competing
teams, helping them find a good resolution.

What I have found works is...
* Agree on a common set of user problems that need to be solved now
* ... and at the same time, gain a better understanding of where
people need/want to go in the future

That way, everyone starts to focus their efforts in the same direction.

What I would keep

In summary, I would keep most things. The Nova project is thriving.

The focus on "cloud" and not "server virt" should continue. That
doesn't mean we shouldn't work well at the small scale, we should work
well at both the large scale and the small scale. We should not stop
the work evolving the architecture of Nova and working out how to
evolve the API. Indeed, we also need to continue to improve how we
interface with Neutron, Glance, etc, etc.

We should also continue to avoid Nova scope creep, and continue to
reduce the scope of Nova where possible:
* split out nova-scheduler, to help cross project scheduling
* deprecate nova-network, or/and split it out of nova
* keep on the look out for other ideas

There are several people I would trust to be a good PTL for the next
cycle, which shows how much Russell has managed to scale out the
leadership in recent cycles. This drive to scale out the leadership of
Nova should continue.

But there are growing pains that need urgent attention...

What I would change

This is not about what we should build in Juno, it's how I'm thinking
the Nova community and Nova leadership should evolve during Juno:

1) Connecting developers with those "using" Nova

We are a very developer driven community. I would like to work with
deployers, packagers, and all users, to get their voices heard by the
Nova developer community.

The improved blueprint reviews and improved triaging of bugs are a
good start, but we need to continue to innovate here. Glance have
included a Product Manager, Brian Rosmaita, on their drivers team. I
am sure Nova would benefit from getting Product Managers, Operators,
and others, more involved in setting project priorities.

One idea: Agree on rough focus areas for each release. Focus areas are
a level of detail where everyone can engage, but with enough detail to
be useful in setting priorities of blueprints and bugs. Efforts that
match the focus areas can be given a higher priority in the review
queue. Example focus areas could be: unified cli, interoperability,
smoother upgrades, etc.

We will know we have got this right when we understand the bug and
blueprint backlog, users feel they are being listened to, and
developers are happy they know where efforts fit into the bigger
picture, and have clear ideas on where they can help.

2) Making it easier to get (more) involved

We need better mentoring of those who are new to Nova, and those
considering joining nova-core or nova-drivers. We have done some great
work to help codify what is expected of people, but there is still a
lot of "tribal" knowledge that, without mentoring, can take a long
time to learn. IRC chats, followed by a face to face chats at the
summit, really helped me feel welcome. We need to invest more time
doing this kind of thing.

Most developers in the community work for a company as a professional
developer. This gives us a fantastic talent pool. However, the needs
of the company and the needs of the wider community can seem at odds.
We need to help make it easier to get involved "in the right way", and
mentoring is a good start.

As someone who works in the UK timezone, I feel we need to be more
receptive to those in non-US timezones. Continuing the rotation of the
Nova meeting is certainly an important step. But I'm sure there is
more we can do to increase the world wide participation on the back of
great work the foundation is doing there.

Right now, some people are feeling frustrated by the current review
and bug backlog. Some feel like their hard work is being ignored. It
can all make Nova feel "cliquey". We will know we have succeeded, when
Nova feels more welcoming and inclusive. In addition, people will know
what it would take to get more involved, should they want to.

3) Feature "Classification"

The drive for better testing of the nova compute drivers has really
helped during Icehouse. I remember the massive impact on master
stability when the first gate tests were added. I think we should
expand this effort in Juno.

We should consider extending the "Classification" to all features,
covering things like:
* MySQL 5.5 vs PostgreSQL vs TubaEuphoniumDB
* RabbitMQ 3.1 vs RabbitMQ 3.2 vs zeromq etc...
* XenServer 6.2 vs XCP 1.1 vs libvirt 1.1 etc...
* nova-network vs neutron, cells vs non-cells
* Ceph vs iSCSI + Swift
* vi vs emacs (just kidding...)

This would be a carrot (and a stick I guess) for getting more people
involved with the maintenance of features they add into Nova. It may
not be totally workable in its current form, but the idea is to make
clear what sort of contribution works best. It would give us a much
clearer view of when features are no longer actively maintained, and
should be deprecated, and possibly removed.

Fundamentally, I feel we need to be open to our users about:
* what is working
* what is untested upstream
* what we know doesn't work

The classification could be based around things like:
* level of automated testing (none, hourly + on-demand, every commit,
gate, number of skipped tempest tests)
* level of documentation (user and developer setups)
* active bug maintainers / blueprint reviewers / test failure contacts
on IRC and email

To make this more concrete, this would include expanding the detail in
the current compute driver classification and support matrix:

This will have worked if people understand how best to responsibly
contribute new Nova features, and it is easy for their employers to
understand and support that. In addition, we would have an open
understanding of what parts of Nova are well maintained.

Thanks for reading!

John Garbutt

More information about the OpenStack-dev mailing list