mirror of
https://github.com/geerlingguy/ansible-role-apache
synced 2025-01-10 11:50:18 +01:00
Update examples for modern ansible and state that duplicating parameters causes an error.
This commit is contained in:
parent
59ba91f064
commit
675fb88483
1 changed files with 22 additions and 24 deletions
|
@ -2,23 +2,26 @@
|
|||
|
||||
# this is a bit of an advanced topic.
|
||||
#
|
||||
# generally Ansible likes to pass simple key=value arguments to modules. It occasionally comes up though
|
||||
# that you might want to write a module that takes COMPLEX arguments, like lists and dictionaries.
|
||||
# generally Ansible likes to pass simple key=value arguments to modules. It
|
||||
# occasionally comes up though that you might want to write a module that takes
|
||||
# COMPLEX arguments, like lists and dictionaries.
|
||||
#
|
||||
# happen, at least right now, it should be a Python module, so it can leverage some common code in Ansible that
|
||||
# makes this easy. If you write a non-Python module, you can still pass data across, but only hashes that
|
||||
# do not contain lists or other hashes. If you write the Python module, you can do anything.
|
||||
# In order for this to happen, at least right now, it should be a Python
|
||||
# module, so it can leverage some common code in Ansible that makes this easy.
|
||||
# If you write a non-Python module, you can still pass data across, but only
|
||||
# hashes that do not contain lists or other hashes. If you write the Python
|
||||
# module, you can do anything.
|
||||
#
|
||||
# note that if you were to use BOTH the key=value form and the 'args' form for passing data in, the key=value
|
||||
# parameters take a higher priority, so you can use them for defaults, which can be useful.
|
||||
# note that if you were to use BOTH the key=value form and the 'args' form for
|
||||
# passing data in, the behaviour is currently undefined. Ansible is working to
|
||||
# standardize on returning a duplicate parameter failure in this case but
|
||||
# modules which don't use the common module framework may do something
|
||||
# different.
|
||||
|
||||
- hosts: all
|
||||
user: root
|
||||
- hosts: localhost
|
||||
gather_facts: no
|
||||
|
||||
vars:
|
||||
defaults:
|
||||
state: stopped
|
||||
complex:
|
||||
ghostbusters: [ 'egon', 'ray', 'peter', 'winston' ]
|
||||
mice: [ 'pinky', 'brain', 'larry' ]
|
||||
|
@ -32,16 +35,11 @@
|
|||
ping: data='Hi Mom'
|
||||
|
||||
- name: but what if you have a complex module that needs complicated data?
|
||||
action: ping
|
||||
args:
|
||||
ping:
|
||||
data:
|
||||
moo: cow
|
||||
asdf: [1,2,3,4]
|
||||
|
||||
- name: can we make that cleaner? sure!
|
||||
action: ping
|
||||
args: { data: "{{ complex }}" }
|
||||
|
||||
- name: here is an example of how it works with defaults, notice the key=value format wins
|
||||
action: service name=httpd state=running
|
||||
args: defaults
|
||||
ping:
|
||||
data: "{{ complex }}"
|
||||
|
|
Loading…
Reference in a new issue