Hi, 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. Background ========== 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 cloud. 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. Process ======= 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 adopting. The key thing, lets continue this evolution, so we can scale out the community, keep the quality high, but while keeping everyone productive. 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: https://wiki.openstack.org/wiki/HypervisorSupportMatrix#Driver_Testing_Status 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. Conclusion ========== 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. johnthetubaguy __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
