Open Stack

Excerpts from Matthew Thode's message of 2017-05-30 16:11:41 -0500:
> On 05/30/2017 04:08 PM, Emilien Macchi wrote:
> > On Tue, May 30, 2017 at 8:36 PM, Matthew Thode
> > <prometheanfire at gentoo.org> wrote:
> >> We have a problem in requirements that projects that don't have the
> >> cycle-with-intermediary release model (most of the cycle-with-milestones
> >> model) don't get integrated with requirements until the cycle is fully
> >> done.  This causes a few problems.
> >>
> >> * These projects don't produce a consumable release for requirements
> >> until end of cycle (which does not accept beta releases).
> >>
> >> * The former causes old requirements to be kept in place, meaning caps,
> >> exclusions, etc. are being kept, which can cause conflicts.
> >>
> >> * Keeping the old version in requirements means that cross dependencies
> >> are not tested with updated versions.
> >>
> >> This has hit us with the mistral and tripleo projects particularly
> >> (tagged in the title).  They disallow pbr-3.0.0 and in the case of
> >> mistral sqlalchemy updates.
> >>
> >> [mistral]
> >> mistral - blocking sqlalchemy - milestones
> >>
> >> [tripleo]
> >> os-refresh-config - blocking pbr - milestones
> >> os-apply-config - blocking pbr - milestones
> >> os-collect-config - blocking pbr - milestones
> > 
> > These are cycle-with-milestones., like os-net-config for example,
> > which wasn't mentioned in this email. It has the same releases as
> > os-net-config also, so I'm confused why these 3 cause issue, I
> > probably missed something.
> > 
> > Anyway, I'm happy to change os-*-config (from TripleO) to be
> > cycle-with-intermediary. Quick question though, which tag would you
> > like to see, regarding what we already did for pike-1?
> > 
> > Thanks,
> > 
> 
> Pike is fine as it's just master that has this issue.  The problem is
> that the latest release blocks the pbr from upper-constraints from being
> coinstallable.

The issue is that even with beta releases like we publish at
milestones, new versions of these projects won't be installed in
gate jobs because we have to give pip special instructions to allow
pre-releases and we, as a rule, do not give it those instructions.
The result is that we need anything that is going to be installed
as via pip to be releasable at any point in the cycle, to address
dependency issues like we're dealing with here, and that means
changing the model back to cycle-with-intermediary.

This isn't something I foresaw when we talked about making all of
the TripleO components use a consistent model in the past. I'm sorry
for the oversight.

Doug