[openstack-dev] [TripleO] Let's use Ansible to deploy OpenStack services on Kubernetes
Bogdan Dobrelya
bdobreli at redhat.com
Fri Jul 14 16:14:42 UTC 2017
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.
>
> 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.
>> Flavio
>> --
>> @flaper87
>> Flavio Percoco
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
--
Best regards,
Bogdan Dobrelya,
Irc #bogdando
More information about the OpenStack-dev
mailing list