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

Dan Prince dprince at redhat.com
Mon Apr 4 00:27:20 UTC 2016

On Wed, 2016-03-23 at 19:11 +0000, Fox, Kevin M wrote:
> If heat convergence worked (Is that a thing yet?), it could
> potentially be used instead of a COE like kubernetes.
> The thing ansible buys us today would be upgradeability. Ansible is
> config management, but its also a workflow like tool. Heats bad at
> workflow.
> I think between Heat with Convergence, Kolla containers, and some
> kind of Mistral workflow for upgrades, you could replace Ansible.

There is nothing I've seen that Kolla/Ansible does that we can't do
with Heat, Mistral, and Containers. We just need to decide how we want
to architect it and do it. We've got a proof of concept we can iterate
on with the Compute role... I'd like to see more details about
comparing that approach to using something like Kubernetes/Mesos in the

Understood that everyone has their opinions on tooling but from my
prospective there seems to be quite a bit of divergence between Kolla
and what TripleO is striving for. 

We are trying to build a deployment Workflow that converges the UI and
CLI. Having a set of API's around which to build these things is highly
beneficial. Think any UI, not just "a" UI which has hard coded
parameters to work with a given implementation of the Kolla Ansible
scripts. I'm thinking of something like 'heat stack-validate' which
gives you a list of parameter, types, and descriptions up/front base on
the roles and services that your nested stacks configure. This allows
the UI to dynamically discover parameters, and evolve over time to work
with new scripts or plugins with little to no UI coding changes. With
Kolla Ansible I'm not sure how you'd get the equivalent of something
that can dynamically build out your parameters (including types, and
descriptions) without rolling your own tool to manage these things. You
could probably build a tool to do this but I don't see it yet. This is
just one example... we could go deeper but I'm not seeing the lets
replace TripleO heat templates w/ Kolla as a drop in.

Our goal was never to "replace Ansible". The architecture of our
approach to deployment is just different. The architecture of our HA is
different. The services we support are different. How we configure
these services is different.

We do however want to switch to containers. So rather than argue about
tooling I'd rather focus on things we have in common. We are
interested, at least for now I think, in consuming Kolla containers.
And the conversation about whether a COE like kubernetes or mesos might
be more beneficial to Openstack deployment is actually worth
collaborating on. In short I think the two projects could have much in
common with regards to the containers and the architecture that manages
them. Lets start there and leave the workflow tooling opinions to the
side for now.


> Then there's the nova instance user thing again (https://review.opens
> tack.org/222293)... How do you get secrets to the instances
> securely... Kubernetes has a secure store we could use... OpenStack
> still hasn't really gotten this one figured out. :/ Barbican is a
> piece of that puzzle, but there's no really good to hook it and nova
> together. 
> Thanks,
> Kevin
> ________________________________________
> From: Michał Jastrzębski [inc007 at gmail.com]
> Sent: Wednesday, March 23, 2016 8:42 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [TripleO][Heat][Kolla][Magnum] The zen
> of Heat, containers, and the future of TripleO
> 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.
> 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/invent
> > ory/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:unsu
> > bscribe
> > 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:unsubs
> cribe
> 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:unsubs
> cribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

More information about the OpenStack-dev mailing list