[openstack-dev] [TripleO][Heat][Kolla][Magnum] The zen of Heat, containers, and the future of TripleO

Adam Young ayoung at redhat.com
Wed Mar 23 15:51:31 UTC 2016

On 03/23/2016 11:42 AM, Michał Jastrzębski wrote:
> Hello,
> So Ryan, I think you can make use of heat all the way. Architecture of
> kolla doesn't require you to use ansible at all (in fact, we separate
> ansible code to a different repo). Truth is that ansible-kolla is
> developed by most people and considered "the way to deploy kolla" by
> most of us, but we make sure that we won't cut out other deployment
> engines from our potential.
> So bottom line, heat may very well replace ansible code if you can
> duplicate logic we have in playbooks in heat templates. That may
> require docker resource with pretty complete featureset of docker
> itself (named volumes being most important). Bootstrap is usually done
> inside container, so that would be possible too.

Heat can call Anisble.

Why would it not be Heats responsibility for creating the stack, and 
then Kolla-ansible for setting everything up?

Heat is more esoteric than Ansible.  I expcet the amount of people that 
know and use Ansible to far outweight the number of people that know 
Heat.  Let's make it easy for them to get involved.  Use each as 
appropriate, but let the config with Heat clearly map to a config 
without it for a Kolla based deploy.

> To be honest, as for tripleo doing just bare metal deployment would
> defeat idea of tripleo. We have bare metal deployment tools already
> (cobbler which is used widely, bifrost which use ansible same as kolla
> and integration would be easier), and these comes with significantly
> less footprint than whole tripleo infrastructure. Strength of tripleo
> comes from it's rich config of openstack itself, and I think that
> should be portable to kolla.
> On 23 March 2016 at 06:54, Ryan Hallisey <rhallise at redhat.com> 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.
>> Thanks!
>> -Ryan
>> [1] - https://github.com/openstack/kolla/blob/master/ansible/inventory/multinode
>> [2] - https://github.com/rthallisey/kolla-heat-templates
>> [3] - https://review.openstack.org/#/c/255450/
>> __________________________________________________________________________
>> 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