>>> 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. I didn't know heat can call Ansible. Now that I know that let me refine. I think it would be nice to have heat use kolla-ansible. With split-stack/composable-roles, the tripleo-heat-templates are going to undergo major reconstruction. So then the questions are, do we construct the templates to 1) use kolla-ansible or 2) rewrite them with kolla-ansible logic in heat or 3) go with kolla-kubernetes. 1) This solution involves merging the kolla and tripleo communities. kolla-tripleo maybe? This path will come to a solution significantly faster since it will be completely leveraging the work kolla has done. I think ansible is a good tool, but I don't know if it's the best for container deployment/management. 2) This solution is right along the lines of dprince's patch series [1], but with focus on deploying kolla's containers. This option has a longer road than 1. I think it could work and I think it would be a good solution. > 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. 3) Kolla-kubernetes is only a spec at this point, but with kubernetes the undercloud would use magnum. This option to me, has the most upside, but the longest road. I think the cluster management tools: replication controllers, health checks, deployments, ect., would be great additions. My excitement around kolla-ansible stems from the fact that it is significantly farther along than kolla-kubernetes. I haven't done a deployment of kolla-kuberenetes since we dropped it a year ago. But having done an evaluation of it recently, I think it's the best option long term. Until I use it with kolla + magnum, I won't know for certain. Thanks, -Ryan [1] - https://review.openstack.org/#/c/295588/5 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
