[openstack-dev] [TripleO] Let's use Ansible to deploy OpenStack services on Kubernetes

Steven Dake steven.dake at gmail.com
Fri Jul 14 19:38:48 UTC 2017


On Fri, Jul 14, 2017 at 10:26 AM, James Slagle <james.slagle at gmail.com>
wrote:

> 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.
>
> James,


> 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.
>
>
I think what you are saying in a nutshell is that TripleO and Kolla compete.


> 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 you are saying here is Kolla chose to compete on tooling.  I
haven't really given it a lot of thought; I'd say all are technical choices
made with Kolla had mostly to do with selecting wisely from the technical
ecosystem.


> 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.
>
>
I believe it wise that you don't jump to any conclusion or solution that
does or doesn't use Helm.  I'd encourage you to understand how Kubernetes
works before making such technical choices.

All that said, there is clearly value in working together rather than
apart.  To me, that is more important then the technical choices you are
presented with.

Regards
-steve


> --
> -- 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170714/68698ccd/attachment.html>


More information about the OpenStack-dev mailing list