Open Stack

On Tue, Aug 25, 2015, at 05:32 AM, Thierry Carrez wrote:
> Thierry Carrez wrote:
> > [...]
> > 1. Enable master->stable cross-check
> > 2. Release Oslo, make stable branches for Oslo
> > 2.1 Converge constraints
> > 3. liberty-3 / FF / soft requirements freeze
> > 4. hard requirements freeze
> > 5. RC1 / make stable branches for services
> > 6. Branch requirements, disable cross-check
> > 7. Unfreeze requirements
> 
> I discussed this with Robert this morning on #openstack-relmgr-office
> and it appears the plan is still valid. It was also confirmed in the
> spec at
> http://specs.openstack.org/openstack/openstack-specs/specs/requirements-management.html
> 
> > It still feels reasonable on the face of it, but we need to double-check
> > it and expand on the details. In particular I'm wondering:
> > 
> > * is there anything in the implemented constraints system that changes
> > the deal here ?
> 
> No. Some jobs are not running under the constrained dep system yet, but
> that doesn't make the plan invalid.
> 
> > * Is the new constraints system already set up to work on the upcoming
> > stable/liberty branches ?
> 
> We need to double-check, but by default the stable/liberty code branches
> should test with master requirements until stable/liberty requirements
> are branched out, at which point it should test stable/liberty code with
> stable/liberty requirements.
> 
devstack-gate (which wraps most of this) has a default behavior or
attempting to checkout the change specific ref, falling back to the
change specific branch, and finally using master if everything else
fails. This means that changes to stable/liberty should use master
requirements until we cut a stable/liberty branch on requirements.

The details are actually slightly more complicated than that and you can
read through them at
https://git.openstack.org/cgit/openstack-infra/devstack-gate/tree/functions.sh#n393
> > * what did we exactly mean by "master->stable cross-check" ?
> 
> For completeness, during the transition period (when we use master
> requirements for both master and stable/liberty branches) we need a job
> to gate proposed master requirements changes on stable/liberty test jobs
> in addition to master test jobs. Otherwise we may introduce a change in
> master requirements that breaks stable code branches.
> 
> Once we have stable/liberty requirements branched out, we don't need
> that job anymore.
> 
This however will need to be added to JJB and zuul. If someone can give
me a rough idea of what jobs need to be run in this way (eg what is
sufficient) I can go ahead and work on getting a change to do that
pushed.

Note that this would end up being a special case as we haven't tested
changes to master of projects without stable branches against the stable
branches of projects with the new stable branches in place. This is one
reason I have been a proponent for branching stable early across the
board to ensure stable works and master works and we don't have to worry
about syncing the two.
> > * what did we exactly mean by "Converge constraints" ?
> 
> We need to merge any lingering requirements bump in projects, before we
> create stable/liberty branches for them.
> 
> > With liberty-3 / FF being Thursday next week, we need to start
> > implementing steps 1, 2 and 2.1 in the next 10 days, so we need to
> > urgently check that this is still a valid plan (and any implementation
> > detail).
> 
> The most urgent is to figure out if we can have a master->stable
> cross-check enabled before we start cutting stable/liberty branches.
> Plan B (if we can't) is to apply extra caution to any master
> requirements change during the overlap period, without the gate safety
> net.
> 
Clark