Given this playbook:
--Michael
Hmmm… any ideas for a workaround?
What I’m doing is dividing my playbooks into logical groups of tasks. But sometimes one playbook needs to include tasks from a different group of tasks, e.g., slapd project needs to access openssl project to generate the certificate. Within the context of the openssl project, I have a var $cn that contains the common name for the certificate. But in the slapd project the corresponding value is in the $fqdn var. Somehow I need to pass the fqdn value to the openssl templates, where cn is expected.
--Michael
Hmmm.... any ideas for a workaround?
Nothing easy or elegant, nor that I would recommend to anyone, but if you need to get going:
Calling the setup module would allow you to persist the settings to another metadata file with the variables you chose
to pass down.
setup metadata=/tmp/some_path a=2 b=3 c=$somevar
Would gather facts + a, b, and c, but you would not have other variables in the template unless you passed them to setup.
(If you leave off metadata will use the default path, which would lose variables for other template ops, and would be bad.)
--Michael
You will have to pass metadata=<path> to the template call also, using the same path you fed 'setup'.
Yeah… not very elegant, especially since I’d lose all my regular setup vars.
If we had overlord-local modules, I could write one that would take in vars and return them as facts.
(dev internals discussion, kind of sort of)
So it was once in plan that the template "module" could take key=value options that were used only for that call.
If so, you could do:
template src=… dest=… biz=$biz
And use those variables in addition to whatever else.
I'd like to have that feature back, it's not the fix for this particular problem by any means, but it would be nice. If you can make that happen by Tuesday or so, I can probably get that merged into 0.4.
Even if not -- it's a workable fix we can have on devel.
--Michael
Yes, that would work as a workaround. I’ll try to do that.
OK, so the best I can tell so far, the include params are parsed early – before the setup step, so my host vars are not even getting passed. Am I right? E.g., if I have a host var of $foo, I don’t think I can do this:
tasks:
- include: bar.yaml biz=$foo