Open Stack

confirmed


On Wed, Apr 8, 2015 at 11:25 AM, John Garbutt <john at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Elizabeth Krumbach Joseph || Lyz || pleia2