[OpenStack-Infra] [kolla] making stable/mitaka == stable/liberty

Steven Dake (stdake) stdake at cisco.com
Fri Apr 15 21:39:17 UTC 2016

Hey fellow OpenStackers,

Kolla 1.0.0 has a fatal flaw in its design related to data containers.  The details are outlined here:

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:

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:

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?


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-infra/attachments/20160415/11f1b34d/attachment.html>

More information about the OpenStack-Infra mailing list