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. 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 _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
