Open Stack

On 8 April 2015 at 21:19, Anita Kuno <anteaya at anteaya.info> wrote:
> 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?

Thanks for asking about this.

I covered some of that in the "Code contributions" section above, but
let me highlight a few things...

I agree that we need fairly radical change so we can continue to
scale, BUT we need to ensure we maintain (ideally increase) code
quality and consistency, among other things. There are some great
ideas to chew through at the summit, and we need to pick what we are
doing for liberty after that session. If I become PTL, I am prepared
to ensure a decision is made so we can move forward, even if I have to
pick one of them myself.

Some specific points... Talking with folks, the idea of splitting +W
and +2 groups sounds very interesting, but needs some more thinking.
Nova-core has got too static, and as a result, is now too small. We
need to make it easier for people to leave nova-core, so its easier to
add people. I think the stable maintainers core vs project teams are
showing a level of centralised reviews, but if we go that route, we
need a clear way for a sub teams to form, prove themselves, graduate.
Some of this sometimes doesn't feel open, not totally sure how to fix
that yet, beyond being honest with everyone, asking people to speak up
when they are unhappy, and answering peoples questions quickly and
honestly.

Changes we made for kilo meant less non-priority code was able to
merge. As mentioned above, I am a fan of establishing a Tick-Tock
release cycle, in an attempt to get a good balance between stability
and fixing the big problems our user need fixing. I see
blueprints/specs/features as solutions to problems our users face, the
need for hierarchically quotas would be a good example of that.

We have lots of windows where "you can't do X" for process reasons.
Its high maintenance, and causes lots of friction, and we need ways to
keep focus. We need to work hard to make these windows as small as
possible.

Anyways, I am rambling. If there are specific concerns or ideas, do
reach out to me on IRC, or via whatever works.

Thanks,
John