Open Stack

On Sun, Apr 12, 2015 at 6:09 PM, Robert Collins <robertc at robertcollins.net>
wrote:

> On 13 April 2015 at 12:53, Monty Taylor <mordred at inaugust.com> wrote:
>
> > What we have in the gate is the thing that produces the artifacts that
> > someone installing using the pip tool would get. Shipping anything with
> > those artifacts other that a direct communication of what we tested is
> > just mean to our end users.
>
> Actually its not.
>
> What we test is point in time. At 2:45 UTC on Monday installing this
> git ref of nova worked.
>
> Noone can reconstruct that today.
>
> I entirely agree with the sentiment you're expressing, but we're not
> delivering that sentiment today.
>
> We need to balance the inability to atomically update things - which
> forces a degree of freedom on install_requires - with being able to
> give someone the same install that we tested.
>
> That is the fundamental tension that we're not handling well, nor have
> I seen a proposal to tackle it so far.
>
> I'll have to spend some time noodling on this, but one of the clear
> constraints is that install_requires cannot both be:
>  - flexible enough to permit us to upgrade requirements across many
> git based packages [because we could do coordinated releases of sdists
> to approximate atomic bulk changes]
>  - tight enough enough to give the next person trying to run that ref
> of the package the same things we installed in CI.
>
> -> I think we need something other than install_requires
>
> ...
> > I disagree that anything is broken for us that is not caused by our
> > inability to remember that distro packaging concerns are not the same as
> > our concerns, and that the mechanism already exists for distro pacakgers
> > to do what they want. Furthermore, it is caused by an insistence that we
> > need to keep versions "open" for some ephemeral reason such as "upstream
> > might release a bug fix" Since we all know that "if it's not tested,
> > it's broken" - any changes to upstream software should be considered
> > broken until proven otherwise. History over the last 5 years has shown
> > this to be accurate more than the other thing.
>
> This seems like a strong argument for really being able to reconstruct
> what was in CI.
>
> > If we pin the stable branches with hard pins of direct and indirect
> > dependencies, we can have our stable branch artifacts be installable.
> > Thats awesome. IF there is a bugfix release or a security update to a
> > dependent library - someone can propose it. Otherwise, the stable
> > release should not be moving.
>
> Can we do that in stable branches? We've still got the problem of
> bumping dependencies across multiple packages.
>

We cannot do this today with 'pip install -r requirements.txt' but we can
with 'pip install -r --no-deps requirements.txt'  if requirements includes
all transitive dependencies. And then we have to figure out transitive
dependencies for all projects etc.

What do you mean bumping dependencies across mulitple packages?


>
> -Rob
>
> --
> Robert Collins <rbtcollins at hp.com>
> Distinguished Technologist
> HP Converged Cloud
>
> __________________________________________________________________________
> 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/20150414/a23f893a/attachment.html>