Open Stack

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.
Flavio
--
@flaper87
Flavio Percoco
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 862 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170714/0e288c82/attachment.sig>