Open Stack

Thanks for all the feedback so far. This is one of the things I appreciate the
most about this community, Open conversations, honest feedback and will to
collaborate.

I'm top-posting to announce that we'll have a joint meeting with the Kolla team
on Wednesday at 16:00 UTC. I know it's not an ideal time for many (it's not for
me) but I do want to have a live discussion with the rest of the Kolla team.

Some questions about the meeting:

* How much time can we allocate?
* Can we prepare an agenda rather than just discussing "TripleO is thinking of
  using Ansible and not kolla-kubernetes"? (I'm happy to come up with such
  agenda)

One last point. I'm not interested in conversations around competition,
re-invention, etc. I think I speak for the entire TripleO team when I say that
this is not about "winning" in this space but rather seeing how/if we can
collaborate and how/if it makes sense to keep exploring the path described in
the email below.

Flavio

On 14/07/17 11:17 +0200, 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



--
@flaper87
Flavio Percoco
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 862 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170717/172388ac/attachment.sig>