Open Stack

On Fri, Jan 3, 2014 at 3:13 PM, Sean Dague <sean at dague.net> wrote:

> On 01/03/2014 02:44 PM, Doug Hellmann wrote:
>
>>
>>
>>
>> On Fri, Jan 3, 2014 at 12:45 PM, Joshua Harlow <harlowja at yahoo-inc.com
>> <mailto:harlowja at yahoo-inc.com>> wrote:
>>
>>     Ok, I think I'm fine with that (although not really sure what that
>>     entails).
>>
>>     What does the living under the 'oslo program' change?
>>
>>     Does that entail getting sucked into the incubator (which seems to
>>     be what
>>     your graduating link is about).
>>
>>     I don't think its a good idea for taskflow to be in the 'incubator'.
>>     Taskflow is meant to be just like any other 3rd party library.
>>
>>
>> No, as we discussed in Hong Kong, there's no reason to add taskflow to
>> the incubator.
>>
>> Whether or not it needs to be part of the oslo program (or any other
>> program) is a separate question. I'm not opposed to bringing it in, but
>> didn't see the point when it came up at the summit.
>>
>> I understand that moving taskflow into oslo would avoid the policy
>> decision we have in place to not do symmetric gating on unreleased
>> versions of things not "owned" by the OpenStack project. However, I
>> don't know if we want to be testing against the git head of libraries no
>> matter where they live. As fungi pointed out on IRC, gating against
>> pre-release versions of libraries may allow us to reach a state where
>> the software works when installed from git, but not from the released
>> packages.
>>
>> It seems safer to gate changes to libraries against the apps' trunk (to
>> avoid making backwards-incompatible changes), and then gate changes to
>> the apps against the released libraries (to ensure they work with
>> something available to be packaged by the distros). There are lots and
>> lots of version numbers available to us, so I see no problem with
>> releasing new versions of libraries frequently.
>>
>> Am I missing something that makes that not work?
>>
>
> Requirements wedging.
>
> Because of entry points any library that specifies any dependencies that
> OpenStack components specify, at incompatible levels, means that library
> effectively puts a hold on the rest of OpenStack and prevents it from being
> able to move forward.
>

I have considered changing stevedore so it uses entry points to find
plugins, but then handles the import itself specifically to eliminate the
requirements checks for plugin dependencies enforced by pkg_resources. So
far I haven't convinced myself that it's a good idea, but I'm open to
discussion. :-)



>
> Which means every time we need to then change a library dependency it's
> going to require triggering a release, solely to change library
> dependencies.
>
> This is the giant disaster that we created global requirements to avoid,
> so that we have one nob to turn.
>
> The only other option is that libraries we own (stackforge / oslo), for
> condition to be included in global- requirements, *can never* specify a
> maximum version of any dependency (and I really mean never), and can never
> specify a minimum greater than current global requirements.


That seems like a more appealing solution than testing against unreleased
versions via git checkouts. It is is also an approach we could encourage
authors of libraries we don't own to use.

Doug



>
>
>         -Sean
>
> --
> Sean Dague
> Samsung Research America
> sean at dague.net / sean.dague at samsung.com
> http://dague.net
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140103/1c58f0a7/attachment.html>