Open Stack

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.

-Rob

-- 
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud