For example, say I have file, .bashrc that I want to write to my target
host during the cloud-init process. In some cases, like with CoreOS which
sets files like this one read-only once cloud-init is complete, there are
things you can do during cloud-init that you cannot do afterwards
(otherwise I'd just use template module as usual). To make this happen
with Ansible, I need to include the content of the file within the
cloud-init YAML string which is passed in to the user_data field of the ec2
ansible module. I would like to store a template like bashrc.j2 so I could
modify it before it gets used within the user_data string as part of that
cloud_init text, rather than awkwardly as part of a variable file in YAML
format with a bunch of other files.
On Friday, 8 August 2014 14:34:25 UTC-7, Michael Peters wrote:
>
> I don't know if you know this, but variables can themselves be
> templated. You can do this in a set_fact or even in a variable file
> (group_vars, host_vars, var_files, etc).
>
> For instance:
>
> set_fact: foo={% if yada %}{{ (blah + baz) / 100 }}{% else %}{{ fiddly
> * 100 }}{% endif %}
>
> Or in a var file:
>
> foo: {% if yada %}{{ (blah + baz) / 100 }}{% else %}{{ fiddly * 100
> }}{% endif %}
>
> So what case would a template file accomplish that template
> expressions wouldn't ?
>
> On Fri, Aug 8, 2014 at 5:30 PM, AJ Daws <[email protected] <javascript:>>
> wrote:
> > Michael, no need to apologize, you've already helped a lot, thank you!
> >
> > One thing that would really help here and is general enough I'm sure it
> > would find use elsewhere as well is to have the template module capable
> of
> > outputting to a variable rather than a file. That certainly would help
> me
> > in my case, and I've seen cases elsewhere while trying to improve my
> code
> > for this where it would also have been helpful.
> >
> > On Friday, 8 August 2014 07:45:43 UTC-7, Michael DeHaan wrote:
> >>
> >> I'm sorry, I found your use case too confusing for me to understand -
> no
> >> offense implied - with what you were doing with lookup plugins.
> >>
> >> I can't help you explore it further.
> >>
> >> This may just be the case of a mailing list making it hard to
> communicate,
> >> but things like "The problem is that the output from dumping one
> multiline
> >> variable into another file in YAML format doesn't indent each line to
> comply
> >> with the YAML multiline format. " don't make sense to me.
> >>
> >> Embedding YAML in YAML isn't really a thing, normally you would just
> keep
> >> a datastructure inside the YAML.
> >>
> >> In ansible, you can also use the template module to dump YAML on demand
> >> like so:
> >>
> >> "{{ foo | to_yaml }}"
> >>
> >> Which is really great if you have a datastructure.
> >>
> >> You can also
> >>
> >> "{{ foo | to_json }}"
> >>
> >> I hope this helps somewhat.
> >>
> >>
> >>
> >> On Thu, Aug 7, 2014 at 6:09 PM, AJ Daws <[email protected]> wrote:
> >>>
> >>> include_vars helps by making a chunk of work re-usable; thanks!
> However
> >>> in my use case, I would like to include text in one file into the
> variable
> >>> file to finally be included in a task. I've updated the git
> repository to
> >>> reflect this setup with use of include_vars. The problem is that the
> output
> >>> from dumping one multiline variable into another file in YAML format
> doesn't
> >>> indent each line to comply with the YAML multiline format.
> >>>
> >>> The actual use case here is the use of the ec2 module to create new
> >>> instances, and I am setting the user_data field to some cloud-init
> YAML for
> >>> use in the initial provisioning of CoreOS (I would prefer to use
> Ansible,
> >>> but some of it can only be done as part of this cloudinit process). I
> want
> >>> to write files during this process that are included directly in the
> >>> cloud-config YAML, and so I would prefer to have those files as
> separate
> >>> files in my Ansible setup, such as "bashrc.yml" for example, and
> include
> >>> these inside a "cloudinit.yml" file that constructs the final text to
> use
> >>> for the user_data variable.
> >>>
> >>> I found an awkward way to deal with this, though it does at least
> work.
> >>> One can use the Jinja2 indent filter as I have in the code:
> >>>
> >>> multilinevar_from_included_varfile: |
> >>> var_tests:
> >>> - name: include some script in yaml format
> >>> script: |
> >>> {{ script_content|indent(4) }}"
> >>>
> >>>
> >>> If anyone knows of a cleaner way to do this I'd love to hear it.
> >>>
> >>> Output from updated test without using the Jinja2 'indent' filter:
> >>> var_tests:
> >>> - name: var_from_playbook
> >>> v: var_from_playbook_VALUE
> >>>
> >>> - name: var_from_role
> >>> v: var_from_role_VALUE
> >>>
> >>> - name: include some script in yaml format
> >>> script: #!/bin/bash
> >>> echo this is my script!
> >>> echo notice that the lines in the final output are not indented
> currently
> >>> to be parsed correctly in the task file
> >>>
> >>>
> >>> On Thursday, 7 August 2014 14:23:09 UTC-7, Michael DeHaan wrote:
> >>>>
> >>>> The lookup plugin with "file" can't be used to interpolate variables
> and
> >>>> read them back in.
> >>>>
> >>>> Read the docs on the "include_vars" module and you may be a bit
> happier,
> >>>> and it eliminates the overcomplex lookup attempt.
> >>>>
> >>>>
> >>>> On Wed, Aug 6, 2014 at 7:24 PM, AJ Daws <[email protected]> wrote:
> >>>>>
> >>>>> I created a simple example to demonstrate at
> >>>>> https://github.com/tdaws/ansible-templated-file-to-var-example.
> To try it
> >>>>> directly, you can git clone
> >>>>> https://github.com/tdaws/ansible-templated-file-to-var-example &&
> run-me.sh
> >>>>> Or you can browse the files directly. The run-me.sh script just
> shows
> >>>>> what command I use to call the test.
> >>>>>
> >>>>> Output contains the {{ }} notation instead of the replacement values
> >>>>> desired:
> >>>>>
> >>>>> TASK: [testrole | Test multiline templated var]
> >>>>> *******************************
> >>>>> ok: [localhost] => {
> >>>>> "msg": "#testfile.yml\nvar_tests:\n - name: var_from_playbook\n
> >>>>> v: {{ var_from_playbook }}\n\n - name: var_from_role\n v: {{
> var_from_role
> >>>>> }}"
> >>>>> }
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> On Wednesday, 6 August 2014 08:06:22 UTC-7, Michael DeHaan wrote:
> >>>>>>
> >>>>>> "Tried the lookup('file', 'my-user-data.yml') but it does not
> appear
> >>>>>> to be parsed by jinja2"
> >>>>>>
> >>>>>> Not sure why this would be the case but would need to see the
> >>>>>> playbook.
> >>>>>>
> >>>>>> Needs to be surrounded by "{{ }}" to evaluate of course, which may
> be
> >>>>>> part of the problem.
> >>>>>>
> >>>>>>
> >>>>>> On Tue, Aug 5, 2014 at 8:17 PM, Amr Ali <[email protected]> wrote:
> >>>>>>>
> >>>>>>> Why not just use a variables file, along with include_vars.. you
> can
> >>>>>>> even use a group or hosts var file..
> >>>>>>>
> >>>>>>> What kind of "templating" options are you looking into using?
> >>>>>>>
> >>>>>>> --
> >>>>>>> You received this message because you are subscribed to the Google
> >>>>>>> Groups "Ansible Project" group.
> >>>>>>> To unsubscribe from this group and stop receiving emails from it,
> >>>>>>> send an email to [email protected].
> >>>>>>> To post to this group, send email to [email protected].
> >>>>>>> To view this discussion on the web visit
> >>>>>>>
> https://groups.google.com/d/msgid/ansible-project/f7f83a30-61e6-4619-afe2-d3487ae36b02%40googlegroups.com.
>
>
> >>>>>>> For more options, visit https://groups.google.com/d/optout.
> >>>>>>
> >>>>>>
> >>>>> --
> >>>>> You received this message because you are subscribed to the Google
> >>>>> Groups "Ansible Project" group.
> >>>>> To unsubscribe from this group and stop receiving emails from it,
> send
> >>>>> an email to [email protected].
> >>>>> To post to this group, send email to [email protected].
> >>>>> To view this discussion on the web visit
> >>>>>
> https://groups.google.com/d/msgid/ansible-project/ff6d36d1-103d-4528-8459-07ff43ac71b0%40googlegroups.com.
>
>
> >>>>>
> >>>>> For more options, visit https://groups.google.com/d/optout.
> >>>>
> >>>>
> >>> --
> >>> You received this message because you are subscribed to the Google
> Groups
> >>> "Ansible Project" group.
> >>> To unsubscribe from this group and stop receiving emails from it, send
> an
> >>> email to [email protected].
> >>> To post to this group, send email to [email protected].
> >>> To view this discussion on the web visit
> >>>
> https://groups.google.com/d/msgid/ansible-project/f4ddc9f1-50e5-41ad-8ec5-50d3560ac09d%40googlegroups.com.
>
>
> >>>
> >>> For more options, visit https://groups.google.com/d/optout.
> >>
> >>
> > --
> > You received this message because you are subscribed to the Google
> Groups
> > "Ansible Project" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> an
> > email to [email protected] <javascript:>.
> > To post to this group, send email to [email protected]
> <javascript:>.
> > To view this discussion on the web visit
> >
> https://groups.google.com/d/msgid/ansible-project/b7fd3793-08ea-4704-86d6-8d2a8c538894%40googlegroups.com.
>
>
> > For more options, visit https://groups.google.com/d/optout.
>
--
You received this message because you are subscribed to the Google Groups
"Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/ansible-project/563dead0-3657-4950-94d3-ff460e5912c6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
