Open Stack

On 01/03/2014 04:17 PM, Doug Hellmann wrote:
>
>
>
> On Fri, Jan 3, 2014 at 4:08 PM, Sean Dague <sean at dague.net
> <mailto:sean at dague.net>> wrote:
>
>     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>
>         <mailto: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>__>
>                  <mailto: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.
>
>
> 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.

There is a reason the Linux distros don't blindly follow what libraries 
say they depend on, because humans are foulable, and can only look 
backwards and not forwards in time.

	-Sean

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