Open Stack

On 4/16/16, 3:24 PM, "Doug Hellmann" <doug at doughellmann.com> wrote:

>Excerpts from Steven Dake (stdake)'s message of 2016-04-15 21:39:17 +0000:
>> 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.
>
>We discussed an option 4, which is make the mitaka version of kolla able
>to install liberty versions of OpenStack. Can you remind me why that
>wouldn't work? Was it because of dependency conflicts?
>
>Doug

Doug,

I don't recall the exact technical details however there are also policy
decisions in play.  Michal (cc) is responsible for our backporting of
Liberty.  I believe the technical objection had something to do with
making upgrades from one to another not viable.  We also have a
long-standing policy decision that one repo should only deploy one version
of OpenStack.  We at this point are not ready to take on the concept of
deploying N and N-1 from one repository.  The reasons are complex but I
could expand if you like.

I'll let Michal respond though with his own thoughts, as I don't know his
precise technical objection.

>From a project policy perspective, we have made past decisions we don't
want to have n and n-1 deploy and operational implementations in one
repository.  I'd have to trigger a vote to change that policy if that is
the only path forward acceptable to the release team.

All kolla policy changes require a majority vote (7 +1 votes) of the core
review team within a 1 week window.  If you indicate option 2 is a
non-starter and option 4 is our only path forward, I'll trigger a vote and
hope for the best :)

Option 2 is what we as a community want.  Option #4 is not what we as a
community want at this time, although that may change in the future as our
project becomes more mature.  With option #4 would come the requirement
that we delete the stable/liberty branch, because as it stands now, this
branch has a fatal flaw which cannot be fixed as enumerated at length in
this thread.

Regards
-steve

>
>> 
>> 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?
>> 
>> Thanks!
>> -steve
>
>_______________________________________________
>OpenStack-Infra mailing list
>OpenStack-Infra at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra