Open Stack

On Fri, Jan 16, 2015 at 12:25 PM, Joe Gordon <joe.gordon0 at gmail.com> wrote:

> We can side step the dependency graphing and ordering issue by looking at
> the list of curently installed packages via pip freeze and not installing
> dependencies (pip install --no-deps)
>
> After looking into this further here are the known issues:
>
> * Partial capping won't work [0], so we need to pin all dependencies, we
> can generate this list per file via "pip install -r" and "pip freeze", but
> this doesn't address the issue of apt-get vs pip install. For example in
> the stable gate we use suds 0.4.1 but only suds 0.4.0 is available via pip.
> * Not all packages are installed in are standard dsvm-tempest env, so
> using pip-freeze from that isn't enough
> * We need to run this per requirements file and move to using pip install
> --no-deps everywhere. As the global-requirements sync wouldn't work the
> first time since files don't list all transient dependencies yet.
> * We can still break if a package version is removed from pypi
> * in pip-freeze we sometimes install versions lower then our minimum
> version (python-libvirt!)
>
>
Exploring a few ideas here: https://review.openstack.org/#/c/147451/4


>
>
> [0]
> http://lists.openstack.org/pipermail/openstack-dev/2015-January/054156.html
>
> On Fri, Jan 16, 2015 at 5:07 AM, Jeremy Stanley <fungi at yuggoth.org> wrote:
>
>> On 2015-01-15 08:44:58 -0500 (-0500), Sean Dague wrote:
>> [...]
>> > The other thing that happened was partial capping doesn't work,
>> > because something else moves forward and breaks you from below. So
>> > the patch will need to hit everything at once.
>>
>> Right, and we _have_ to start using stable branches on all
>> clients/libraries to backport fixes as part of that. This means that
>> the stable branch management workflow is about to become pervasive
>> across some teams who were previously (blissfully?) ignorant of it.
>>
>> > Unresolved entirely is the tertiary dependencies (not direct
>> > dependencies of any OpenStack project). That will need another
>> > mechanism to seed them before any installation happens.
>> [...]
>>
>> I won't go so far as to call it intractable, but I took a stab at it
>> about a year ago and building the dependency graph properly to be
>> able to do a depth-first ordering is nontrivial (enough that after
>> about a week hacking on possible solutions I gave up and switched to
>> more productive tasks). The primary complications I ran into were
>> identifying setup_requires in transitive dependencies and dealing
>> with platform/version-specific dependencies. That said, there's a
>> very good chance that more recent improvements in setuptools, pip
>> and virtualenv could make this task easier.
>>
>> > That's the things I can think off from the top of my head.
>>
>> The implementation, from a devstack-gate perspective, is also going
>> to require a decision on whether we stick with stable/relname for
>> branches of libraries too or switch to some extended branch mapping
>> mechanism to be able to track stable/relnum branches for those. And
>> we're going to need more jobs to ensure that clients (specifically)
>> retain backward-compatibility from an appdev and end user
>> perspective since they'll no longer get any testing as server
>> dependencies on stable branches (due to being capped there).
>> --
>> Jeremy Stanley
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> 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/20150116/c941ece2/attachment.html>