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

Ben Nemec openstack at nemebean.com
Fri Jul 14 21:00:42 UTC 2017

On 07/14/2017 11:43 AM, Joshua Harlow wrote:
> Out of curiosity, since I keep on hearing/reading all the tripleo 
> discussions on how tripleo folks are apparently thinking/doing? 
> redesigning the whole thing to use ansible + mistral + heat, or ansible 
> + kubernetes or ansible + mistral + heat + ansible (a second time!) or ...
> Seeing all those kinds of questions and suggestions around what should 
> be used and why and how (and even this thread) makes me really wonder 
> who actually uses tripleo and can afford/understand such kinds of changes?
> Does anyone?
> If there are <some folks/operators?> is there going to be an upgrade 
> path for there existing 'cloud/s' to whatever this solution is?
> What operator(s) has the ability to do such a massive shift at this 
> point in time? Who are these 'mystical' operators?
> All this has really peaked my curiosity because I am personally trying 
> to do that shift (not exactly the same solution...) and I know it is a 
> massive undertaking (that will take quite a while to get right) even for 
> a simple operator with limited needs out of openstack (ie godaddy); so I 
> don't really understand how the generic solution for all existing 
> tripleo operators can even work...

This is a valid point.  Up until now the answer has been that we 
abstracted most of the ugliness of major changes behind either Heat or 
tripleoclient.  If we end up essentially dropping those two in favor of 
some other method of driving deployments it's going to be a lot harder 
to migrate.  And I could be wrong, but I'm pretty sure it _is_ important 
to our users to have an in-place upgrade path (see the first bullet 
point in [1]).

New, shiny technology is great and all, but we do need to remember that 
we have a lot of users out there already depending on the old, 
not-so-shiny bits too.  They're not going to be happy if we leave them 

1: http://lists.openstack.org/pipermail/openstack-dev/2017-June/119063.html

> Flavio Percoco wrote:
>> Greetings,
>> As some of you know, I've been working on the second phase of TripleO's
>> containerization effort. This phase if about migrating the docker based
>> deployment onto Kubernetes.
>> These phase requires work on several areas: Kubernetes deployment,
>> OpenStack
>> deployment on Kubernetes, configuration management, etc. While I've been
>> diving
>> into all of these areas, this email is about the second point, OpenStack
>> deployment on Kubernetes.
>> There are several tools we could use for this task. kolla-kubernetes,
>> openstack-helm, ansible roles, among others. I've looked into these
>> tools and
>> I've come to the conclusion that TripleO would be better of by having
>> ansible
>> roles that would allow for deploying OpenStack services on Kubernetes.
>> The existing solutions in the OpenStack community require using Helm.
>> While I
>> like Helm and both, kolla-kubernetes and openstack-helm OpenStack
>> projects, I
>> believe using any of them would add an extra layer of complexity to
>> TripleO,
>> which is something the team has been fighting for years years -
>> especially now
>> that the snowball is being chopped off.
>> Adopting any of the existing projects in the OpenStack communty would
>> require
>> TripleO to also write the logic to manage those projects. For example,
>> in the
>> case of openstack-helm, the TripleO team would have to write either 
>> ansible
>> roles or heat templates to manage - install, remove, upgrade - the
>> charts (I'm
>> happy to discuss this point further but I'm keepping it at a 
>> high-level on
>> purpose for the sake of not writing a 10k-words-long email).
>> James Slagle sent an email[0], a couple of days ago, to form TripleO 
>> plans
>> around ansible. One take-away from this thread is that TripleO is 
>> adopting
>> ansible more and more, which is great and it fits perfectly with the
>> conclusion
>> I reached.
>> Now, what this work means is that we would have to write an ansible role
>> for
>> each service that will deploy the service on a Kubernetes cluster.
>> Ideally these
>> roles will also generate the configuration files (removing the need of
>> puppet
>> entirely) and they would manage the lifecycle. The roles would be
>> isolated and
>> this will reduce the need of TripleO Heat templates. Doing this would 
>> give
>> TripleO full control on the deployment process too.
>> In addition, we could also write Ansible Playbook Bundles to contain
>> these roles
>> and run them using the existing docker-cmd implementation that is coming
>> out in
>> Pike (you can find a PoC/example of this in this repo[1]).
>> Now, I do realize the amount of work this implies and that this is my
>> opinion/conclusion. I'm sending this email out to kick-off the
>> discussion and
>> gather thoughts and opinions from the rest of the community.
>> Finally, what I really like about writing pure ansible roles is that
>> ansible is
>> a known, powerfull, tool that has been adopted by many operators
>> already. It'll
>> provide the flexibility needed and, if structured correctly, it'll allow
>> for
>> operators (and other teams) to just use the parts they need/want without
>> depending on the full-stack. I like the idea of being able to separate
>> concerns
>> in the deployment workflow and the idea of making it simple for users of
>> TripleO
>> to do the same at runtime. Unfortunately, going down this road means
>> that my
>> hope of creating a field where we could collaborate even more with other
>> deployment tools will be a bit limited but I'm confident the result
>> would also
>> be useful for others and that we all will benefit from it... My hopes
>> might be a
>> bit naive *shrugs*
>> Flavio
>> [0]
>> http://lists.openstack.org/pipermail/openstack-dev/2017-July/119405.html
>> [1] https://github.com/tripleo-apb/tripleo-apbs
>> -- 
>> @flaper87
>> Flavio Percoco
>> __________________________________________________________________________ 
>> 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
> __________________________________________________________________________
> 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

More information about the OpenStack-dev mailing list