Open Stack

On 14.7.2017 23:00, Ben Nemec wrote:
> 
> 
> 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
> hanging.

Exactly. Reuse is nice to have, while some sort of an upgrade path is a 
must have. We should be aware of this when selecting tools for Kubernetes.

Jirka

> 
> 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
> 
> __________________________________________________________________________
> 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
>