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: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
