ansible/community.general
1
0
Fork 0
mirror of https://github.com/ansible-collections/community.general.git synced 2024-09-14 20:13:21 +02:00
Code Releases Activity

Merge pull request #5567 from risaacson/doc_corrections

Browse source 
A few documentation corrections
This commit is contained in:
Michael DeHaan 2014-01-10 14:52:41 -08:00
commit b0940f0c68
4 changed files with 9 additions and 9 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
docsite/rst/developing_modules.rst
View file

@ -91,7 +91,7 @@ The example usage we are trying to achieve to set the time is::
If no time parameter is set, we'll just leave the time as is and return the current time. If no time parameter is set, we'll just leave the time as is and return the current time.
.. note: .. note::
This is obviously an unrealistic idea for a module. You'd most likely just This is obviously an unrealistic idea for a module. You'd most likely just
use the shell module. However, it probably makes a decent tutorial. use the shell module. However, it probably makes a decent tutorial.

2
docsite/rst/guide_rolling_upgrade.rst
View file

@ -75,7 +75,7 @@ as push updates to all of the servers::
- base-apache - base-apache
- nagios - nagios
.. note: .. note::
If you're not familiar with terms like playbooks and plays, you should review :doc:`playbooks`. If you're not familiar with terms like playbooks and plays, you should review :doc:`playbooks`.

10
docsite/rst/playbooks_intro.rst
View file

@ -96,7 +96,7 @@ documentation. The `remote_user` is just the name of the user account::
- hosts: webservers - hosts: webservers
remote_user: root remote_user: root
.. Note:: .. note::
The `remote_user` parameter was formerly called just `user`. It was renamed in Ansible 1.4 to make it more distinguishable from the `user` module (used to create users on remote systems). The `remote_user` parameter was formerly called just `user`. It was renamed in Ansible 1.4 to make it more distinguishable from the `user` module (used to create users on remote systems).
@ -110,7 +110,7 @@ Remote users can also be defined per task::
ping: ping:
remote_user: yourname remote_user: yourname
.. Note:: .. note::
The `remote_user` parameter for tasks was added in 1.4. The `remote_user` parameter for tasks was added in 1.4.
@ -203,9 +203,9 @@ the service module takes key=value arguments::
- name: make sure apache is running - name: make sure apache is running
service: name=httpd state=running service: name=httpd state=running
The `command` and `shell` modules are the one modules that just takes a list The `command` and `shell` modules are the only modules that just take a list
of arguments, and don't use the key=value form. This makes of arguments and don't use the key=value form. This makes
them work just like you would expect. Simple:: them work as simply as you would expect::
tasks: tasks:
- name: disable selinux - name: disable selinux

4
docsite/rst/playbooks_variables.rst
View file

@ -110,7 +110,7 @@ it's more than that -- you can also read variables about other hosts. We'll sho
Jinja2 Filters Jinja2 Filters
`````````````` ``````````````
.. note: These are infrequently utilized features. Use them if they fit a use case you have, but this is optional knowledge. .. note:: These are infrequently utilized features. Use them if they fit a use case you have, but this is optional knowledge.
Filters in Jinja2 are a way of transforming template expressions from one kind of data into another. Jinja2 Filters in Jinja2 are a way of transforming template expressions from one kind of data into another. Jinja2
ships with many of these as documented on the official Jinja2 template documentation. ships with many of these as documented on the official Jinja2 template documentation.
@ -737,7 +737,7 @@ or in a file as above.
Conditional Imports Conditional Imports
``````````````````` ```````````````````
.. note: this behavior is infrequently used in Ansible. You may wish to skip this section. The 'group_by' module as described in the module documentation is a better way to achieve this behavior in most cases. .. note:: This behavior is infrequently used in Ansible. You may wish to skip this section. The 'group_by' module as described in the module documentation is a better way to achieve this behavior in most cases.
Sometimes you will want to do certain things differently in a playbook based on certain criteria. Sometimes you will want to do certain things differently in a playbook based on certain criteria.
Having one playbook that works on multiple platforms and OS versions is a good example. Having one playbook that works on multiple platforms and OS versions is a good example.