On 31 March 2014 18:53, John Garbutt <j...@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 _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev