Open Stack

tl;dr: it will not happen again because we'll be able to fix our own
bugs and not depend on Ansible policy. Also we don't predict
architectural changes anytime soon as what we have is pretty solid. We
got shot down by our dependencies really.

So reason this thing is even a thing is because of Ansible really. We
used ansible 1.9.4 in Liberty and Mitaka, moving to 2.0+ is high on
our list of priorities. Official docker module in ansible had a bug in
1.9.4 preventing us from using docker higher than 1.8. In docker 1.9
crucial feature was merged that enabled us to have data persistance -
volumes. Thing about ansible was they didn't want to merge bugfix in
1.9 so we were pretty much screwed, can't update docker, can't update
ansible (2.0 wasn't even released back then and it isn't completely
backwards compatible). In Mitaka we wrote our own docker module.

I hope it clarifies it a bit.

Cheers,
Michal

On 18 April 2016 at 03:42, 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.
>
> 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 ?
>
> 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.
>
> --
> Thierry Carrez (ttx)
>
>
> _______________________________________________
> OpenStack-Infra mailing list
> OpenStack-Infra at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra