On Thu, Nov 16, 2017 at 8:44 AM, Flavio Percoco <fla...@redhat.com> wrote: > Integration with TripleO Heat Templates > ======================================= > > This work is on-going and you should eventually see some patches popping-up > on > the reviews list. One of the goals, besides consuming these ansible roles > from > t-h-t, is to be able to create a PoC for upgrades and have an end-to-end > test/demo of this work. > > As we progress, we are trying to nail down an end-to-end deployment before > creating roles for all the services that are currently supported by TripleO. > We > will be adding projects as needed with a focus on the end-to-end goal.
When we consume these ansible-role-k8s-* roles from t-h-t, I think that should be a stepping stone towards migrating away from having to use Heat to deploy and configure those services. We know that these new ansible roles will be deployable standalone, and the interface to do that should be typical ansible best practices (role defaults, vars, etc). We can offer a mechanism such that one can migrate from a tripleo-heat-templates/docker/services/database/mysql.yaml deployed mariadb to one deployed via ansible-role-k8s-mariadb. The config-download mechanism could be updated to generate or pull from Heat the necessary ansible vars files for configuring the roles. We should make sure that the integration with tripleo-heat-templates results in the same inputs/outputs that someone would consume if using the roles standalone. Future iterations would then not have to require Heat for that service at all, unless the operator wanted to continue to configure the service via Heat parameters/environments. What I'm trying to propose is a path towards deprecating the Heat parameter/environment driven and hieradata driven approach to configuring the services. The ansible-role-k8s-* roles should offer a new interface, so I don't think we have to remain tied to Heat forever, so we should consider what we want the long term goal to be in an ideal world, and take some iterative steps to get there. It's probably worthwhile as a thought experiment to update this diagram[0] as to how it might look at different future stages. The first stage might just be t-h-t driven ansible-role-k8s-* , followed by a migration to ansible-role-k8s-* as the primary interface, and then finally perhaps no Heat[1]. [0] https://slagle.fedorapeople.org/tripleo-ansible-arch.png [1] Except for perhaps deployment of baremetal resources, but even then I'm personally of the opinion that would be better serviced by Mistral->Ansible->Ironic directly. -- -- James Slagle -- __________________________________________________________________________ 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