Open Stack

An initial WIP patch to show the direction I think this could
materialize - https://review.openstack.org/125346

Early feedback appreciated so I can do this conversion across the board.
My assumption is that all non integrated release projects should be
converted to this model.

On 09/26/2014 02:27 PM, Sean Dague wrote:
> As we've been talking about the test disaggregation the hamster wheels
> in the back of my brain have been churning on the library testing
> problem I think we currently have. Namely, openstack components mostly
> don't rely on released library versions, they rely on git master of
> them. Right now olso and many clients are open masters (their
> stable/juno versions are out), but we've still not cut RCs on servers.
> So we're actually going to have a time rewind event as we start cutting
> stables.
> 
> We did this as a reaction to the fact that library releases were often
> cratering the world. However, I think the current pattern leads us into
> a much more dangerous world where basically the requirements.txt is invalid.
> 
> So here is the particular unwind that I think would be useful here:
> 
> 1) Change setup_library in devstack to be able to either setup the
> library from git or install via pip. This would apply to all libraries
> we are installing from oslo, the python clients, stackforge, etc.
> Provide a mechanism to specify LIBRARIES_FROM_GIT (or something) so that
> you can selectively decide to use libraries from git for development
> purposes.
> 
> 2) Default devstack to use pip released versions.
> 
> 3) Change the job definition on the libraries to test against devstack
> in check, not in gate. The library teams can decide if they want their
> forward testing to be voting or not, but this is basically sniff testing
> that when they release a new library they won't ruin the world for
> everyone else.
> 
> 4) If a ruin the world event happens, figure out how to prevent that
> kind of event in local project testing, unit or functional. Basically an
> unknown contract was broken. We should bring that contract back into the
> project itself, or yell at the consuming project about why they were
> using code in a crazy pants way.
> 
> Additionally, I'd like us to consider: No more alpha libraries. The
> moment we've bumped global requirements in projects we've actually
> released these libraries to production, as people are CDing the servers.
> We should just be honest about that and just give things a real version.
> Version numbers are cheap.
> 
> 	-Sean
> 


-- 
Sean Dague
http://dague.net