[openstack-dev] [TripleO][Heat][Kolla][Magnum] The zen of Heat, containers, and the future of TripleO
imain at redhat.com
Wed Mar 23 17:11:07 UTC 2016
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.
> I'm also in favor of using Magnum to deploy a COE to manage Kolla. I'm much less thrilled about Mesos though. It feels heavy enough weight that it feels like your deploying an OpenStack like system just to deploy OpenStack. So, OpenStack On NotOpenStack On OpenStack. :/ I've had good luck with Kubernetes (much simpler) recently and am disappointed that it was too immature at the time Kolla originally considered it. It seems much more feasible to use now. I use net=host like features all the time which was a major sticking point before.
> I'd be interested in seeing TripeO use the Ansible version for now since that's working, stable, and supports upgrades/oddball configs. Then in the future as Kubernetes support or maybe Mesos support matures, consider that. Kolla's going to have to have a migration path from one to the other eventually... I think this would allow TripeO to really come into its own as an end to end, production ready system sooner.
This is very much my thinking as well. I like your pragmatic take on it.
The community is building solutions to these problems and we should join
More information about the OpenStack-dev