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

Michał Jastrzębski inc007 at gmail.com
Sat Apr 16 23:06:35 UTC 2016


Hey,

So reason I don't really like having 2 different versions of openstack
is because it's messy. That means having optional 2 different paths of
deployment, and while they are mostly the same, there are subtle
differences. My initial patchset actually did deploy 2 versions of
openstack, but that require manual labor of configuring build config
and lots of "if liberty, else" which lowered both code readibility and
reliability, as it's additional logic. Then this is policy decision as
we, kolla community, generally want to deploy N relase, so liberty
deploys liberty and so forth. If we create 2 deploys per release, that
will cause mess. Another thing is we specifically don't want people to
deploy current stable/liberty because it is well, not stable. And it's
not stable in potentially very destructive way. We want to discourage
anyone from deploying current stable liberty to a point of actually
removing this branch in favor of mitaka code.

Doug, while I understand your reluctance, it is ugly thing, this is
where we are and our first (I don't know if I can speak for everyone,
but at least for me) priority is quality of deployment we provide.
Bending the rules and policies is worth it if the improvement is this
big, and potentially can save people from catastrophic failure and
data loss.

Cheers,
Michal

On 16 April 2016 at 17:57, Steven Dake (stdake) <stdake at cisco.com> wrote:
>
>
> 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
>
>
> _______________________________________________
> OpenStack-Infra mailing list
> OpenStack-Infra at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra



More information about the OpenStack-Infra mailing list