[openstack-dev] [all] concrete proposal on changing the library testing model with devstack-gate

Sean Dague sean at dague.net
Fri Sep 26 18:27:51 UTC 2014

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

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

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 Dague

More information about the OpenStack-dev mailing list