<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Nov 16, 2017 at 11:56 AM, James Slagle <span dir="ltr"><<a href="mailto:james.slagle@gmail.com" target="_blank">james.slagle@gmail.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
<br>
</span>When we consume these ansible-role-k8s-* roles from t-h-t, I think<br>
that should be a stepping stone towards migrating away from having to<br>
use Heat to deploy and configure those services. We know that these<br>
new ansible roles will be deployable standalone, and the interface to<br>
do that should be typical ansible best practices (role defaults, vars,<br>
etc).<br>
<br>
We can offer a mechanism such that one can migrate from a<br>
tripleo-heat-templates/docker/<wbr>services/database/mysql.yaml deployed<br>
mariadb to one deployed via<br>
ansible-role-k8s-mariadb. The config-download mechanism could be<br>
updated to generate or pull from Heat the necessary ansible vars files<br>
for configuring the roles. We should make sure that the integration<br>
with tripleo-heat-templates results in the same inputs/outputs that<br>
someone would consume if using the roles standalone. Future iterations<br>
would then not have to require Heat for that service at all, unless<br>
the operator wanted to continue to configure the service via Heat<br>
parameters/environments.<br>
<br>
What I'm trying to propose is a path towards deprecating the Heat<br>
parameter/environment driven and hieradata driven approach to<br>
configuring the services. The ansible-role-k8s-* roles should offer a<br>
new interface, so I don't think we have to remain tied to Heat<br>
forever, so we should consider what we want the long term goal to be<br>
in an ideal world, and take some iterative steps to get there.<br></blockquote><div><br></div><div>I like the idea of a leaner set of deployment tooling very much. I think we are to the point where we need to consider "clean rooming" some things.</div><div><br></div><div>That said in moving towards a new interface like you talk about I think we do have to have feature parity with things like composability and parameter validation. Otherwise we are going to break things we currently rely on in our high level (Mistral) deployment workflow. Specifically, I've yet to see something that would give us the nested parameter validations we leverage from Heat.</div><div><br></div><div>Dan</div></div></div></div>