[openstack-dev] [requirements] - taskflow preventing sqla 0.8 upgrade

Sean Dague sean at dague.net
Fri Jan 3 23:32:32 UTC 2014


On 01/03/2014 06:14 PM, Joshua Harlow wrote:
> Since the library model is what most everyone else uses outside of
> openstack (I assume?) what can we do to get there so that this model works
> as well?
>
> Expanding dependencies recursively seems like it could help? This could
> then detect transitive dependency issues (and doesn't seem so hard to do).

We actually talked about having pip be able to help us here with a 
--requirements-override piece of function. dstufft seemed positive on 
the concept.

> I like the idea of 'gate on all the things' (that I've heard come up
> before) but I don't know if its possible? If we hooked into the pypi
> upload 'stream' it would seem like we could automatically trigger
> openstack builds when a known dependency (or dependency of a
> dependency...) is uploaded (maybe?). That would be pretty neat.
 >
> In general it really seems like having more libraries, not less is ideal
> (making us solve this issue whether we want to or not really). As
> libraries can then be used outside of openstack (taskflow is already being
> used elsewhere also), libraries create well-defined apis and boundaries
> between programs (...). I know they also create this dependency hell
> problem (anvil has been hitting these same issues for a while to). But I
> think we can figure out a solution that fits both worlds, the world of
> things we can gate on and the world of things we can't (3rd party
> libraries that aren't under openstack control). Taskflow is in-between
> those worlds, so it allows us to explore how to make both of those worlds
> work.

In general I agree.... however, if you get between OpenStack and SQLA 
you've now touched the 3rd rail. Because we have deep experience about 
how bad the compatibility between versions can be, and we can't be 
beholden to another project about our SQLA upgrade timeframe.

So I think that generalities aside, if are a library, and use SQLA, we 
probably need to really think about putting it in the integrated gate.

Because otherwise what we are saying is taskflow is completely dictating 
the SQLA version in the Icehouse release of OpenStack. And that's the 
wrong place for that decision to be.

If taskflow worked with a storage callback mechanism, and got a storage 
interface from the program that was calling it, then things would be 
much different. But because it's going straight to the database and 
managing tables directly, through a known unstable library, that 
OpenStack itself needs some control over, it's definitely a different case.

	-Sean

-- 
Sean Dague
Samsung Research America
sean at dague.net / sean.dague at samsung.com
http://dague.net



More information about the OpenStack-dev mailing list