Open Stack

On 01/03/2014 05:10 PM, Ivan Melnikov wrote:
> On 04.01.2014 01:29, Sean Dague wrote:
>> On 01/03/2014 04:17 PM, Doug Hellmann wrote:
> [...]
>>> That's what made me think of the solution. But isn't setuptools in fact
>>> telling us that somehow the versions of things we expected to have
>>> installed are no longer installed and so something *is* broken (even if
>>> the versions of the installed libraries work together).
>>
>> It actually tells us that a human, somewhere, decided that their
>> software did not work with some combination of other software, and that
>> we are no longer able to correct their mistaken assumptions.
> [...]
>
> But sometimes humans are not wrong. For example, no released TaskFlow
> version really works with SQLAlchemy >= 0.8 -- that was fixed only
> recently (https://review.openstack.org/#/c/62661/).
>
> I consider requirements to be part of the code, so if they are too
> strict (or too broad), that must be fixed, in a usual opensource way:
> via filing bug report, suggesting patch and so on.
>
> Requirements should reflect reality, especially for libraries that are
> intended to be useful outside of OpenStack, too. For example, current
> TaskFlow requirement for SQLAlchemy is too strict, so we'll fix that,
> and release new version with that fix.

Well part of the problem is because of it being a dependency of a 
dependency, our global requirements process couldn't explore whether or 
not it functioned in a real environment.

Which brings us back to the idea of making this a project that works in 
the integrated gate.

It's also kind of problematic that apparently the introduction of 
taskflow actually caused a regression from Havana (which the distros 
managed to make work with sqla 0.8 even though it wasn't in global 
requirements, but this apparently would have broken).

And the next question is when is a sqla 0.9 compatible version going to 
be out there? Because we can't even explore allowing openstack to use 
sqla 0.9 until taskflow does, again because it's a blocking requirement.

It's exactly these kind of lock step problems that we avoid with the 
rest of openstack by making it an integrated gate with global 
requirements sync. But that we can't really handle with the library model.

	-Sean

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