Open Stack

On 04/08/2015 02:25 PM, John Garbutt 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
In the interest of fairness in the "getting to know the PTL candidate",
a question was posed by a community member to one of the Nova PTL
candidates who posted their nomination to the mailing list previously.
Would you be willing to address the same issue, which I believe is Nova
code review workflow, for the benefit of the electorate?