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

Steven Hardy shardy at redhat.com
Wed Mar 23 21:36:57 UTC 2016

On Wed, Mar 23, 2016 at 01:01:03AM +0000, Fox, Kevin M wrote:
> +1 for TripleO taking a look at Kolla.
> Some random thoughts:
> I'm in the middle of deploying a new cloud and I couldn't use either TripleO or Kolla for various reasons. A few reasons for each:
>  * TripeO - worries me for ever having to do a major upgrade of the software, or needing to do oddball configs like vxlans over ipoib.
>  * Kolla - At the time it was still immature. No stable artefacts posted. database container recently broke, little documentation for disaster recovery. No upgrade strategy at the time.
> Kolla rearchitected recently to support oddball configs like we've had to do at times. They also recently gained upgrade support. I think they are on the right path. If I had to start fresh, I'd very seriously consider using it.
> I think Kolla can provide the missing pieces that TripleO needs. TripleO has bare metal deployment down solid. I really like the idea of using OpenStack to deploy OpenStack. Kolla is now OpenStack so should be considered.

As mentioned in another reply, one of the aims of current refactoring work
in TripleO is to enable folks to leverage the barematal (and networking)
aspects of TripleO, then hand off to another tool should they so wish.

This could work really well if you wanted to layer ansible deployed kolla
containers on top of some TripleO deployed nodes (in fact it's one of the
use-cases we had in mind when deciding to do it).

I do however have several open questions regarding kolla (and the various
other ansible based solutions like openstack-ansible):

- What does the HA model look like, is active/active HA fully supported
  accross multiple controllers?
- Is SSL fully supported for the deployed services?
- Is IPv6 fully supported?
- What integration exists for isolation of network traffic between
- What's the update/upgrade model, what downtime is associated with minor
  version updates and upgrades requiring RPC/DB migration?  What's tested
  in CI in this regard?

Very interested to learn more about these, as they are challenges we've
been facing within the TripleO community lately in the context of our
current implementation.

Regardless of the answers I think moving towards a model where we enable
more choice and easier integration between the various efforts (such as the
split-stack model referred to above) is a good thing and I definitely
welcome building on the existing collaboration we have between the TripleO,
Kolla and other deployment focussed communities.


More information about the OpenStack-dev mailing list