confirmed
On Wed, Apr 8, 2015 at 11:25 AM, John Garbutt <j...@johngarbutt.com> wrote: > 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: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Elizabeth Krumbach Joseph || Lyz || pleia2 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev