Open Stack

On Fri, Apr 15, 2016, at 02:39 PM, Steven Dake (stdake) wrote:
> Hey fellow OpenStackers,
> 
> Kolla 1.0.0 has a fatal flaw in its design related to data containers. 
> The details are outlined here:
> http://docs.openstack.org/developer/kolla/liberty-deployment-warning.html
> 
> Our plan to rectify this involves taking what is in stable/mitaka and
> making it stable/liberty and placing 1-3 patches on top of stable/liberty
> to make it deploy the liberty version of openstack.  These 1-3 patches
> include metadata like repo locations, upstream tarball locations, etc. 
> No actual code.  This is a one time thing; in the future we will be
> following a strict bug-backport only policy.
> 
> Our options include:
> 1. make a megapatch diff of liberty vs mitaka and merge that, with a
> patch on top to fix the repos
> Example here:
> https://review.openstack.org/#/c/306625/
> 
> 2. Tag the tip of stable/liberty with liberty-early-demise, delete the
> liberty branch, then create a new stable/liberty branch from the tip of
> stable/mitaka
> 
> 3. Tag the tip of stable/liberty with liberty-early-demise, and run git
> reset -hard origin/stable/mitaka outside of gerrit.  Tonyb says our setup
> prevents non-fast-forwarded pushes so this might not be viable.
> 
> This was tonyb's work here:
> http://paste.openstack.org/raw/494295/
> 
> What we want to avoid is jamming 1k+ patches through our CI system and
> having the core reviewers have to deal with acking all those patches, or
> overloading gerrit and breaking things there.
> 
> I am far from a git wizard, and don't really know the best way to
> proceed, other  than we must have a liberty 1.1.0 deliverable with our
> mitaka bits + liberty repo pointers.  I'd really like to preserve
> history.  What we need is for stable/liberty to be an exact duplicate of
> stable/mitaka codwise, while also preserving history (which option 1
> doesn't do).
> 
> Can the Kolla community get an ack on the options from the Infrastructure
> team one way or another, so I can get the ball rolling on our end and
> sync up with Doug on the plan?

Is there some reason that the normal backport process used on all of the
other projects wouldn't work here? Backport the bug fixes you need from
the newer branches then release a 1.1.0.

Clark