Open Stack

On Wed, Mar 23, 2016 at 1:34 PM, Zane Bitter <zbitter at redhat.com> wrote:
> On 23/03/16 07:54, Ryan Hallisey wrote:
>>
>> *Snip*
>>
>>> Indeed, this has literally none of the benefits of the ideal Heat
>>> deployment enumerated above save one: it may be entirely the wrong tool
>>> in every way for the job it's being asked to do, but at least it is
>>> still well-integrated with the rest of the infrastructure.
>>
>>
>>> Now, at the Mitaka summit we discussed the idea of a 'split stack',
>>> where we have one stack for the infrastructure and a separate one for
>>> the software deployments, so that there is no longer any tight
>>> integration between infrastructure and software. Although it makes me a
>>> bit sad in some ways, I can certainly appreciate the merits of the idea
>>> as well. However, from the argument above we can deduce that if this is
>>> the *only* thing we do then we will end up in the very worst of all
>>> possible worlds: the wrong tool for the job, poorly integrated. Every
>>> single advantage of using Heat to deploy software will have evaporated,
>>> leaving only disadvantages.
>>
>>
>> I think Heat is a very powerful tool having done the container integration
>> into the tripleo-heat-templates I can see its appeal.  Something I learned
>> from integration, was that Heat is not the best tool for container
>> deployment,
>> at least right now.  We were able to leverage the work in Kolla, but what
>> it
>> came down to was that we're not using containers or Kolla to its max
>> potential.
>>
>> I did an evaluation recently of tripleo and kolla to see what we would
>> gain
>> if the two were to combine. Let's look at some items on tripleo's roadmap.
>> Split stack, as mentioned above, would be gained if tripleo were to adopt
>> Kolla.  Tripleo holds the undercloud and ironic.  Kolla separates config
>> and deployment.  Therefore, allowing for the decoupling for each piece of
>> the stack.  Composable roles, this would be the ability to land services
>> onto separate hosts on demand.  Kolla also already does this [1]. Finally,
>> container integration, this is just a given :).
>>
>> In the near term, if tripleo were to adopt Kolla as its overcloud it would
>> be provided these features and retire heat to setting up the baremetal
>> nodes
>> and providing those ips to ansible.  This would be great for kolla too
>> because
>> it would provide baremetal provisioning.
>>
>> Ian Main and I are currently working on a POC for this as of last week
>> [2].
>> It's just a simple heat template :).
>>
>> I think further down the road we can evaluate using kubernetes [3].
>> For now though,  kolla-anisble is rock solid and is worth using for the
>> overcloud.
>
>
> My concern about kolla-ansible is that the requirements might start getting
> away from what the original design was intended to cope with, and that it
> may prove difficult to extend. For example, I wrote about the idea of doing
> the container deployments with pure Heat:
>
>>> What's more, we are going to need some way of redistributing services
>>> when a machine in the cluster fails, and ultimately we would like that
>>> process to be automated, which would *require* a template generation
>>> service.
>>>
>>> We certainly *could* build all of that. But we definitely shouldn't
>
>
> and to my mind kolla-ansible is in a similar category in that respect (it
> does, of course, have an existing community and in that sense is still
> strictly superior to the pure-Heat approach). There's lots of stuff in e.g.
> Kubernetes that it seems likely we'll want and, while there's no
> _theoretical_ obstacle to implementing them in Ansible, these are hard,
> subtle problems which are presumably better left to a specialist project.

Fully agree with Zane here. I'm not really excited by using anything
other than Kubernetes for container orchestration (unless it's mesos,
but my understanding is it's a bit more heavyweight). Though I am
certainly okay with using kolla-ansible to generate config for all the
OpenStack services, but if it's faster to use puppet then that's fine
too.

The only drawback that I know of is that the Kolla containers would
need modifying since Kubernetes has no notion of dependencies. But
perhaps I'm getting ahead of myself...

> I'd be happy to hear other opinions on that though. Maybe we don't care
> about any of that container cluster management stuff, and if something fails
> we just let everything run degraded until we can pull in a replacement? I
> don't know.