Open Stack

On 01/03/2014 03:30 PM, Doug Hellmann wrote:
>
>
>
> On Fri, Jan 3, 2014 at 3:13 PM, Sean Dague <sean at dague.net
> <mailto: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>
>         <mailto: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. :-)

Well, about 1/3 of our requirements wedges are actually completely entry 
point related. They were a class of problems we never had before we 
switched to entry points.

This entire taskflow block wouldn't have been a problem if it wasn't 
loaded with entry points.

	-Sean

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