I actually like the idea of moving to kolla-kubernetes. I guess there would be a bunch of work towards giving folks an upgrade path and reaching feature parity; but this would happen anyway eurgh the switch to kubernetes. And this would have the added value of merging two communities, thus more devs and folks testing :D . I like it!
On 14 Jul 2017 18:56, "Michał Jastrzębski" <inc...@gmail.com> wrote: Guys.... you just described Kolla-Kubernetes pretty much... how about we join effort and work towards this goal together? 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. > 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
__________________________________________________________________________ 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
