I think thats a good question without an easy answer. I think TripleO's own struggle with orchestration has shown that its maybe one of the hardest pieces. There are a lot of orchestration tools out there. Each has its strengths/weaknesses. I personally can't really pick what the best one is for this sort of thing. I've been trying to stay neutral, and let the low level kolla-kubernetes components be easily sharable between all the projects that already have chosen an orchestration strategy. I think the real answer is probably that the best orchestration tool for the job depends entirely on the deployment tool. So, TripleO's answer might be different then say, something Ubuntu does.
Kolla-kubernetes has implemented reference orchestration a few different ways now. We deploy the gates using pure shell. Its not the prettiest way but works reliably now. (I would not recommend users do this) We have a document for manual orchestration. (slow and very manual, but you get to see all the pieces, which can be instructive) We have helm based orchestration that bundles several microservice charts into service charts and deploys similarly to openstack-helm. We built them to test the waters of this approach and they do work, but I have doubts they could be made robust enough to handle things like live rolling upgrades of OpenStack. It may be robust enough to do upgrades that require downtimes. I think it also may be hard to debug if the upgrade fails half way through. I admit I could totally be wrong though. Theres also been a couple of ansible based orchestrators that have been proposed. They seem to work well, and I think they would be much easier to extend to do a live rolling OpenStack upgrade. I'd very much like to see an Ansible one finished and kick the tires with it. I do think having both some folks in Kolla-Kubernetes and folks in TripleO independently implement k8s deployment with it shows there is a lot of potential in that form of orchestration and that there's even more room for collaboration between the two projects. Thanks, Kevin ________________________________________ From: Bogdan Dobrelya [bdobr...@redhat.com] Sent: Monday, July 17, 2017 1:10 AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [TripleO] Let's use Ansible to deploy OpenStack services on Kubernetes On 14.07.2017 22:55, Fox, Kevin M wrote: > Part of the confusion I think is in the different ways helm can be used. > > Helm can be used to orchestrate the deployment of a whole service (ex, nova). > "launch these 3 k8s objects, template out this config file, run this job to > init the db, or this job to upgrade the db, etc", all as a single unit. > > It can also be used purely for its templating ability. > > So, "render this single k8s object using these values". > > This is one of the main differences between openstack-helm and > kolla-kubernetes. > > Openstack-helm has charts only for orchestrating the deployment of whole > openstack services. > > Kolla-kubernetes has taken a different track though. While it does use helm > for its golang templater, it has taken a microservices approach to be > shareable with other tools. So, each openstack process (nova-api, > neutron-server, neutron-openvswitch-agent), etc, has its own chart and can be > independently configured/placed as needed by an external orchestration > system. Kolla-Kubernetes microservice charts are to Kubernetes what > Kolla-Containers are to Docker. Reusable building blocks of known tested > functionality and assemblable anyway the orchestration system/user feels is > in their best interest. A great summary! As TripleO Pike docker-based containers architecture rely on Kolla-Containers bits a lot, which is run-time kolla config/bootstrap and build-time images overrides, it seems reasonable to continue following that path by relying on Kolla-Kubernetes microservice Helm charts for Kubernetes based architecture. Isn't it? The remaining question is though, if Kolla-kubernetes doesn't consume the Openstack-helm's opinionated "orchestration of the deployment of whole openstack services", which tools to use then to fill the advanced data parameterization gaps like "happens before/after" relationships and data dependencies/ordering? > > This is why I think kolla-kubernetes would be a good fit for TripleO, as you > can replace a single component at a time, however you want, using the config > files you already have and upgrade the system a piece at a time from non > container to containered. It doesn't have to happen all at once, even within > a single service, or within a single TripleO release. The orchestration of it > is totally up to you, and can be tailored very precisely to deal with the > particulars of the upgrade strategy needed by TripleO's existing deployments. > > Does that help to alleviate some of the confusion? > > Thanks, > Kevin -- 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 __________________________________________________________________________ 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
