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 <fla...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Best regards, Bogdan Dobrelya, Irc #bogdando __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
