Open Stack

On Thu, Nov 16, 2017 at 8:44 AM, Flavio Percoco <flavio at 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
--