Open Stack

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.

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
________________________________________
From: James Slagle [james.slagle at gmail.com]
Sent: Friday, July 14, 2017 10:26 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [TripleO] Let's use Ansible to deploy OpenStack services on Kubernetes

On Fri, Jul 14, 2017 at 12:16 PM, Fox, Kevin M <Kevin.Fox at pnnl.gov> wrote:
> https://xkcd.com/927/

That's cute, but we aren't really trying to have competing standards.
It's not really about competition between tools.

> I don't think adopting helm as a dependency adds more complexity then writing more new k8s object deployment tooling?

That depends, and will likely end up containing a fair amount of
subjectivity. What we're trying to do is explore choices around
tooling.

>
> There are efforts to make it easy to deploy kolla-kubernetes microservice charts using ansible for orchestration in kolla-kubernetes. See:
> https://review.openstack.org/#/c/473588/
> What kolla-kubernetes brings to the table is a tested/shared base k8s object layer. Orchestration is done by ansible via TripleO, and the solutions already found/debugged to how to deploy OpenStack in containers on Kubernetes can be reused/shared.

That's good, and we'd like to reuse existing code and patterns. I
admit to not being super famliliar with kolla-kubernetes. Are there
reusable components without having to also use Helm?

> See for example:
> https://github.com/tripleo-apb/ansible-role-k8s-keystone/blob/331f405bd3f7ad346d99e964538b5b27447a0ebf/provision-keystone-apb/tasks/main.yaml

Pretty sure that was just a POC/example.

>
> I don't see much by way of dealing with fernet token rotation. That was a tricky bit of code to get to work, but kolla-kubernetes has a solution to it. You can get it by: helm install kolla/keystone-fernet-rotate-job.
>
> We designed this layer to be shareable so we all can contribute to the commons rather then having every project reimplement their own and have to chase bugs across all the implementations. The deployment projects will be stronger together if we can share as much as possible.
>
> Please reconsider. I'd be happy to talk with you more if you want.

Just to frame the conversation with a bit more context, I'm sure there
are many individual features/bugs/special handling that TripleO and
Kolla both do today that the other does not.

TripleO had about a 95% solution for deploying OpenStack when
kolla-ansible did not exist and was started from scratch. But, kolla
made a choice based around tooling, which I contend is perfectly valid
given that we are creating deployment tools. Part of the individual
value in each deployment project is the underlying tooling itself.

I think what TripleO is trying to do here is not immediately jump to a
solution that uses Helm and explore what alternatives exist. Even if
the project chooses not to use Helm I still see room for collaboration
on code beneath the Helm/whatever layer.

--
-- James Slagle
--

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev