Open Stack

On 4/18/16, 1:42 AM, "Thierry Carrez" <thierry at openstack.org> wrote:

>Michał Jastrzębski wrote:
>> 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.
>
>The thing is, supporting two versions of OpenStack in a single branch of
>Kolla *is* what you're doing here, only in catastrophic mode. You are
>basically rebuilding a liberty branch from mitaka code + 1-3 patches,
>because stable/mitaka is closer where you want to be than
>stable/liberty. So in essence you are using a single branch with
>conditionals, you are just using branches rather than if statements.

Yup possibly, but if you look into the future of this model that is
Liberty, Mitaka, Newton, Occata.  If these are managed as branches we only
have to maintain 4 ways to deploying OpenStack.  If we do n and n-1, that
is 8 ways.  It doubles our workload around all things relating to keeping
a stable branch stable.

>
>My main gripe is that I don't see why this situation would not happen
>again, and why the same solution wouldn't be have to be applied again...
>Could you explain the steps you are taking that would prevent such a
>situation to happen in the future, to the point where maintaining a
>single code base wouldn't be a better solution ?

Agree looks like a slippery slope.  But it is not.  I really really don't
want to do this.  This feels like an exception to me, and I hate
exceptions, because once an exception is done, it must be one again and
again and again.  I live my life exception free (within the bounds of
pragmatism:).

We have had several environmental shifts in how we manage the repositories
which will prevent this situation from occurring in the future.

We have decoupled our dependence on Ansible for integration with Docker
(If this was in stable/liberty, we wouoldn't even need to do this - as we
could just patch up the data volumes to named volumes).  This decouping
gives us ultimate flexibility to fix critical flaws should they arise in
the future
We are properly using the bug tracking system (which wasn't being done
before) to track bugs for z streams.
We plan to release bug-fix-only z streams which address high/critical bugs
in master for our stable branches (liberty/newton)
We don't have any critical flaws in Kolla tha would require such a change
in the future.

The only feasible thing that could trigger such an event is people wanting
to use ansible 2.0 (rather then ansible 1.9) to deploy Liberty.  My answer
to that is an absolute no - that is a feature and not a critical flaw.
Use the dependencies we specify for the versions we specify.

>
>I don't mind that much for stable/liberty, since it predates the
>"officialness" of Kolla: I'm fine with any solution there. I'm more
>concerned about stable/mitaka and going forward. Stable branches are
>supposed to be known quantities, slow moving and safe changes. What
>you're proposing wouldn't be an option for stable/mitaka -- so I'd like
>to make sure we don't find ourselves in a similar situation in the future.

Going forward this will not happen again.  I agree a stable branch should
be a slow rate of change repository but also a safe place to rely on.  At
present stable/liberty is completely unsafe, so much so that I personally
wrote a document in our docs.oo pages that says "DON'T UE IT".  We are
only backporting high/critical bugs which are legitimate bugs and not
features to our stable branches.  Note we will be backporting any gate
changes, (which could be considered "features", but this is to simplify
our lives so we don't have different gates for different versions of
OpenStack.

The main reason this won't happen again is we have decoupled the ansible
1.9 pin on docker 1.8.2.  Now we can use any version of Docker we need,
which is 1.10 and greater.

Hope the context is useful.

Regards
-steve

>
>-- 
>Thierry Carrez (ttx)
>
>_______________________________________________
>OpenStack-Infra mailing list
>OpenStack-Infra at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra