mirror of
https://github.com/ansible-collections/community.general.git
synced 2024-09-14 20:13:21 +02:00
Issue #84: Doc tweaks for modules, moduledev, and playbooks
This commit is contained in:
parent
b247da54f1
commit
26c141e96e
3 changed files with 15 additions and 5 deletions
|
@ -188,11 +188,13 @@ You should also never do this in a module::
|
||||||
Because the output is supposed to be valid JSON. Except that's not quite true,
|
Because the output is supposed to be valid JSON. Except that's not quite true,
|
||||||
but we'll get to that later.
|
but we'll get to that later.
|
||||||
|
|
||||||
Further, modules must not output anything on stderr, even if the JSON returned
|
Modules must not output anything on standard error, because the system will merge
|
||||||
out stdout is valid. This is due to the internals of our SSH library, more or less.
|
standard out with standard error and prevent the JSON from parsing. Capturing standard
|
||||||
|
error and returning it as a variable in the JSON on standard out is fine, and is, in fact,
|
||||||
|
how the command module is implemented.
|
||||||
|
|
||||||
If a module returns stderr or otherwise fails to produce valid JSON, the actual output
|
If a module returns stderr or otherwise fails to produce valid JSON, the actual output
|
||||||
will still be shown in Ansible, however, but the command will not succeed.
|
will still be shown in Ansible, but the command will not succeed.
|
||||||
|
|
||||||
Always use the hacking/test-module script when developing modules and it will warn
|
Always use the hacking/test-module script when developing modules and it will warn
|
||||||
you about these kind of things.
|
you about these kind of things.
|
||||||
|
|
|
@ -431,7 +431,9 @@ on your remote systems.
|
||||||
|
|
||||||
*variablename*:
|
*variablename*:
|
||||||
|
|
||||||
* Arbitrary names can be used as variables. 'variablename' can be basically anything, and sets a ``key=value`` pair in the JSON file for use in templating.
|
* Arbitrary variable names, which must be a mix of alphanumeric characters and
|
||||||
|
underscores, can also be defined. Setting a variable creates a
|
||||||
|
``key=value`` pair in the JSON file for use in templating.
|
||||||
|
|
||||||
Example action from Ansible :doc:`playbooks`::
|
Example action from Ansible :doc:`playbooks`::
|
||||||
|
|
||||||
|
@ -451,7 +453,7 @@ shell
|
||||||
|
|
||||||
The shell module takes the command name followed by a list of
|
The shell module takes the command name followed by a list of
|
||||||
arguments, space delimited. It is almost exactly like the command module
|
arguments, space delimited. It is almost exactly like the command module
|
||||||
but runs the command through the shell rather than directly.
|
but runs the command through the user's configured shell on the remote node.
|
||||||
|
|
||||||
The given command will be executed on all selected nodes.
|
The given command will be executed on all selected nodes.
|
||||||
|
|
||||||
|
|
|
@ -501,6 +501,12 @@ To save some typing, repeated tasks can be written in short-hand like so::
|
||||||
- testuser1
|
- testuser1
|
||||||
- testuser2
|
- testuser2
|
||||||
|
|
||||||
|
The above would be the equivalent of::
|
||||||
|
|
||||||
|
- name: add user testuser1
|
||||||
|
action: user name=testuser1 state=present groups=wheel
|
||||||
|
- name: add user testuser2
|
||||||
|
action: user name=testuser2 state=present groups=wheel
|
||||||
|
|
||||||
Asynchronous Actions and Polling
|
Asynchronous Actions and Polling
|
||||||
++++++++++++++++++++++++++++++++
|
++++++++++++++++++++++++++++++++
|
||||||
|
|
Loading…
Reference in a new issue