[openstack-dev] [requirements] - taskflow preventing sqla 0.8 upgrade
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
> 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
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.
Samsung Research America
sean at dague.net / sean.dague at samsung.com
More information about the OpenStack-dev