Open Stack

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