Open Stack

On 31 March 2014 18:53, John Garbutt <john at johngarbutt.com> wrote:
> Hi,
>
> 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
> orchestrate.
>
>
> How I see the PTL role
> ----------------------
>
> The basics of the Project Team Lead (or Project Technical Lead) role
> are covered here:
> https://wiki.openstack.org/wiki/PTLguide
>
> 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.

Just to clarify, I am not suggesting we give non-developers +2/-2/+A
on design specifications, but I would like to encourage non-developers
to review design specifications, now that is possible with nova-specs.

As with all these suggestions, they are here to spark better ideas,
and to highlight areas I think we, as a community, should work on.

Thanks,
John

> 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:
> https://wiki.openstack.org/wiki/HypervisorSupportMatrix
>
> 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
> @johnthetubaguy