Open Stack

Excerpts from Bogdan Dobrelya's message of 2017-07-14 18:14:42 +0200:
> On 14.07.2017 17:55, Michał Jastrzębski wrote:
> > Guys.... you just described Kolla-Kubernetes pretty much... how about
> > we join effort and work towards this goal together?
> 
> That's exactly that I'd like we all to do.
> 

Agreed, and ...

> > 
> > On 14 July 2017 at 08:43, Flavio Percoco <flavio at redhat.com> wrote:
> >> On 14/07/17 17:26 +0200, Bogdan Dobrelya wrote:
> >>>
> >>> On 14.07.2017 11:17, Flavio Percoco wrote:
> >>>>
> >>>>
> >>>> Greetings,
> >>>>
> >>>> As some of you know, I've been working on the second phase of TripleO's
> >>>> containerization effort. This phase if about migrating the docker based
> >>>> deployment onto Kubernetes.
> >>>>
> >>>> These phase requires work on several areas: Kubernetes deployment,
> >>>> OpenStack
> >>>> deployment on Kubernetes, configuration management, etc. While I've been
> >>>> diving
> >>>> into all of these areas, this email is about the second point, OpenStack
> >>>> deployment on Kubernetes.
> >>>>
> >>>> There are several tools we could use for this task. kolla-kubernetes,
> >>>> openstack-helm, ansible roles, among others. I've looked into these
> >>>> tools and
> >>>> I've come to the conclusion that TripleO would be better of by having
> >>>> ansible
> >>>> roles that would allow for deploying OpenStack services on Kubernetes.
> >>>>
> >>>> The existing solutions in the OpenStack community require using Helm.
> >>>> While I
> >>>> like Helm and both, kolla-kubernetes and openstack-helm OpenStack
> >>>> projects, I
> >>>> believe using any of them would add an extra layer of complexity to
> >>>> TripleO,
> >>>
> >>>
> >>> It's hard to estimate that complexity w/o having a PoC of such an
> >>> integration. We should come up with a final choice once we have it done.
> >>>
> >>> My vote would go for investing engineering resources into solutions that
> >>> have problems already solved, even by the price of added complexity (but
> >>> that sort of depends...). Added complexity may be compensated with
> >>> removed complexity (like those client -> Mistral -> Heat -> Mistral ->
> >>> Ansible manipulations discussed in the mail thread mentioned below [0])
> >>
> >>
> >> I agree it's hard to estimate but you gotta draw the line somewhere. I
> >> actually
> >> spent time on this and here's a small PoC of ansible+mariadb+helm. I wrote
> >> the
> >> pyhelm lib (took some code from the openstack-helm folks) and I wrote the
> >> ansible helm module myself. I'd say I've spent enough time on this research.
> >>
> >> I don't think getting a full PoC working is worth it as that will require
> >> way
> >> more work for not much value since we can anticipate some of the
> >> complexities
> >> already.
> >>
> >> As far as the complexity comment goes, I disagree with you. I don't think
> >> you're
> >> evaluating the amount of complexity that there *IS* already in TripleO and
> >> how
> >> adding more complexity (layers, states, services) would make things worse
> >> for
> >> not much extra value.
> >>
> >> By all means, I might be wrong here so, do let me know if you're seeing
> >> something I'm not.
> 
> My point was to "trade" complexity described in the "Forming our plans
> around Ansible​" ML thread:
> 
> (3) Mistral calling Heat calling Mistral calling Ansible
> 
> to just
> 
> (3') something calls kolla-kubernetes/openstack-helm, via some wrapper
> composition overlay (which creates complexity), or the like
> 
> While the latter might add complexity like the way you (Flavio) have
> described, the former would remove *another* type of complexity, and the
> result might worth the efforts.
>

The two options seem to be

a. Bootstrap helm and charts and then use openstack-helm/kolla-kubernetes
b. Bootstrap (something) and then use newly minted ansible to manipulate
   kubernetes.

(a) seems like less net complexity, as bootstrapping code is usually
able to be more naive. The new ansible will have to be at least as good
as openstack-helm and kolla-kubernetes, and still needs bootstraps of
its own.