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
> 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
> 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?
OpenStack Development Mailing List (not for usage questions)