[openstack-dev] [all] The future of the integrated release

Matt Joyce dev at openstack.sexy
Wed Aug 6 16:27:59 UTC 2014


On Wed, Aug 06, 2014 at 11:51:27AM -0400, Eoghan Glynn wrote:
> 
> 
> You've touched on multiple trains-of-thought that could indeed
> justify separate threads of their own.
> 
> I agree with your read on the diverging growth rates in the
> strategic versus the tactical elements of the community.
> 
> I would also be supportive of the notion of taking a cycle out to
> fully concentrate on solving existing quality/scaling/performance
> issues, if that's what you meant by pausing to define key cycle
> goals while deferring everything else.
> 
> Though FWIW I think scaling back the set of currently integrated
> projects is not the appropriate solution to the problem of over-
> stretched strategic resources on the QA/infra side of the house.
> 
> Rather, I think the proposed move to in-project functional
> testing, in place of throwing the kitchen sink into Tempest,
> is far more likely to pay dividends in terms of making the job
> facing the QA Trojans more tractable and sustainable.
> 
> Just my $0.02 ...
> 
> Cheers,
> Eoghan
> 

This is where complexity theory trumps automation.

And frankly the problem we're facing here is a monumental one that
has plagued developers for decades.  I think Denis Ritchie got closest
to getting it right.  Small tools that do one job well.  Really well.

Make those tools obey some common rules of behavior and interaction.

But don't let a tool do more than one thing well.  When you do, you
end up with infighting among developers and complexity that's
unsustainable.

I think glance is a great example of going one step too far with
artifacts.  This isn't in scope for what glance is.  It's really
enough of a deviation from glances core function to merit the spin
up of a new tool.  And we shouldn't be afraid of letting people
spin up tools.  Hell they will anyways.  If there's a road block
in front of a developer they'll route around it.

What we need to do is make sure that developers have a list of
requirements they can meet so as not to end up routing too far
around and ending up in some dangerous territory.  We have some
of that already, but it could be cleaned up and codified better.

That's not to say cenralized clearing houses don't work.  Oslo 
works because it's just a clearing house of small bits of 
functionality that people can commonly focus on.  Kind of like GNU 
tools.  That's n-scaling nested in an umbrella project.

Tempest is a vertical.  Glance artifacts are the first step
in turning glance into a vertical.  These are things we need
to try to avoid.

That's my USD$.02

-Matt



More information about the OpenStack-dev mailing list