Okay, my example kind of sucks and I'm not surprised that you noticed.
I had to implement this approach after finding that ansible_env.HOME did
what it should, but not what I needed.
The playbooks run with "sudo: yes" because it was maddening to declare
sudo state for each task. That makes ansible_env.HOME evaluate to
"/root". This is how I solved that problem, but it became difficult
to reuse code that had {{ansible_home_result.stdout}} everywhere.
The pattern is generally applicable for converting any dictionary pair
into a single value variable.
I'm not sure how durable this solution will be since it depends on the
pre_task executing and updating the global dictionary before the role is
evaluated. I feel like its depending on an implied behavior instead of
a contract. A "setvar" solution like you proposed would be superior
because the behavior is explicit.
On 3/21/14, 4:20 PM, Michael DeHaan wrote:
If you do "ansible hostname -m setup" in recent versions, you should
see that environment variables are provided, in which case you can
pull $HOME from there.
This of course would only work for the active user.
http://docs.ansible.com/faq.html#how-do-i-access-shell-environment-variables
On Fri, Mar 21, 2014 at 6:46 PM, Grant BlahaErath <gr...@spryhive.com
<mailto:gr...@spryhive.com>> wrote:
Old thread, but it popped up in my goog when I was looking for
answers. Since I worked out two different solutions, I wanted to
share them.
1)
I needed to get a user account home directory and share it with a
role. Just using register meant I would have to use
"variable.stdout" everywhere. Instead I used the pre_tasks
section of the playbook to retrieve the value and then pulled the
key/value out on the role's variable declaration. Here's the code
I used. I hope this helps out others.
pre_tasks:
- name: Get ansible_user home directory
shell: 'getent passwd "{{ansible_ssh_user}}" | cut -d: -f6'
register: ansible_home_result
roles:
- { role: boxprep_debian, ansible_home:
'{{ansible_home_result.stdout}}', when: ansible_os_family ==
'Debian' }
- { role: boxprep_redhat, ansible_home:
'{{ansible_home_result.stdout}}', when: ansible_os_family ==
'RedHat' }
2)
Another approach that is far more elaborate but can solve anything
is to create a python application that uses jinja2, and then
process all your .yml files as if they were jinja2 templates. The
python application can solve any kind of variable instantiation
challenge while leaving the .yml reusable for other scenarios.
Because jinja2 will only process the template variables it is
told to, it will leave other {{variables}} for ansible to define.
I use this approach to query an elaborate AWS cluster, and then
preprocess the ansible scripts.
On Thursday, March 14, 2013 6:19:43 PM UTC-7, Will Thames wrote:
Let's say that I want to use a variable if it's passed to
ansible-playbook (via -e) and derive it otherwise
I can use register to get the results of the derivation, but
the actual information I need is then typically in the stdout
property.
Is there a better way to do the following ?
---
...
tasks:
- name: derive latest 2.5 release
local_action: shell ls /var/releases/v2.5-* | tail -1
register: release
when_unset: $version
- name: register version into release
local_action: command echo $version
register: release
when_set: $version
I would prefer the second task to be something like this
(rather than having to store the result of echoing the property!)
- name: store release.stdout into version
local_action: variable name=version value=${release.stdout}
when_unset: $version
And then just use $version after that.
Hope that makes sense - basically I just want to be able to
set arbitrary variables during a playbook run rather than just
before.
An alternative would be if register could be given an
attribute that says 'only store stdout' (or stderr or any
other property)
e.g.
register: property=stdout release
or
register: property=rc returncode
Will
--
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 ansible-project+unsubscr...@googlegroups.com
<mailto:ansible-project+unsubscr...@googlegroups.com>.
To post to this group, send email to
ansible-project@googlegroups.com
<mailto:ansible-project@googlegroups.com>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/ansible-project/ac43d9a7-b385-4312-a2ea-790e654a39bd%40googlegroups.com
<https://groups.google.com/d/msgid/ansible-project/ac43d9a7-b385-4312-a2ea-790e654a39bd%40googlegroups.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to a topic in the
Google Groups "Ansible Project" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/ansible-project/wqiclLkqmGU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
ansible-project+unsubscr...@googlegroups.com
<mailto:ansible-project+unsubscr...@googlegroups.com>.
To post to this group, send email to ansible-project@googlegroups.com
<mailto:ansible-project@googlegroups.com>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/ansible-project/CAEVJ8QODgHkQJPNPMVCii73ChsF8RGaHaHajkiZDwdEC4vPN6w%40mail.gmail.com
<https://groups.google.com/d/msgid/ansible-project/CAEVJ8QODgHkQJPNPMVCii73ChsF8RGaHaHajkiZDwdEC4vPN6w%40mail.gmail.com?utm_medium=email&utm_source=footer>.
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 ansible-project+unsubscr...@googlegroups.com.
To post to this group, send email to ansible-project@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/ansible-project/532CD0B2.3070203%40spryhive.com.
For more options, visit https://groups.google.com/d/optout.
