Misc documentation update (#50190)
Signed-off-by: Abhijeet Kasurde <akasurde@redhat.com>
This commit is contained in:
parent
b2f6259259
commit
ff49bbd15d
6 changed files with 20 additions and 16 deletions
|
@ -439,7 +439,7 @@ For instance, if you would like to ensure a specific tenant exists on ACI, these
|
|||
state: present
|
||||
|
||||
|
||||
.. hint:: The XML format is more practical when there is a need to template the REST payload (inline), but the YAML format is more convenient for maintaing your infrastructure-as-code and feels more naturely integrated with Ansible playbooks. The dedicated modules offer a more simple, abstracted, but also a more limited experience. Use what feels best for your use-case.
|
||||
.. hint:: The XML format is more practical when there is a need to template the REST payload (inline), but the YAML format is more convenient for maintaining your infrastructure-as-code and feels more naturally integrated with Ansible playbooks. The dedicated modules offer a more simple, abstracted, but also a more limited experience. Use what feels best for your use-case.
|
||||
|
||||
|
||||
More information
|
||||
|
@ -530,7 +530,7 @@ The :ref:`aci_rest <aci_rest_module>` module is a wrapper around the APIC REST A
|
|||
All below issues either have been reported to the vendor, and most can simply be avoided.
|
||||
|
||||
Too many consecutive API calls may result in connection throttling
|
||||
Starting with ACI v3.1 the APIC will actively throttle password-based authenticated connection rates over a specific treshold. This is as part of an anti-DDOS measure but can act up when using Ansible with ACI using password-based authentication. Currently, one solution is to increase this treshold within the nginx configuration, but using signature-based authentication is recommended.
|
||||
Starting with ACI v3.1 the APIC will actively throttle password-based authenticated connection rates over a specific treshold. This is as part of an anti-DDOS measure but can act up when using Ansible with ACI using password-based authentication. Currently, one solution is to increase this threshold within the nginx configuration, but using signature-based authentication is recommended.
|
||||
|
||||
**NOTE:** It is advisable to use signature-based authentication with ACI as it not only prevents connection-throttling, but also improves general performance when using the ACI modules.
|
||||
|
||||
|
|
|
@ -99,7 +99,7 @@ Storing in a File
|
|||
`````````````````
|
||||
|
||||
When working in a development environment, it may be desirable to store credentials in a file. The modules will look
|
||||
for credentials in $HOME/.azure/credentials. This file is an ini style file. It will look as follows:
|
||||
for credentials in ``$HOME/.azure/credentials``. This file is an ini style file. It will look as follows:
|
||||
|
||||
.. code-block:: ini
|
||||
|
||||
|
@ -260,7 +260,7 @@ If you are not familiar with Ansible's dynamic inventory scripts, check out :ref
|
|||
|
||||
The Azure Resource Manager inventory script is called `azure_rm.py <https://raw.githubusercontent.com/ansible/ansible/devel/contrib/inventory/azure_rm.py>`_. It authenticates with the Azure API exactly the same as the
|
||||
Azure modules, which means you will either define the same environment variables described above in `Using Environment Variables`_,
|
||||
create a $HOME/.azure/credentials file (also described above in `Storing in a File`_), or pass command line parameters. To see available command
|
||||
create a ``$HOME/.azure/credentials`` file (also described above in `Storing in a File`_), or pass command line parameters. To see available command
|
||||
line options execute the following:
|
||||
|
||||
.. code-block:: bash
|
||||
|
|
|
@ -23,11 +23,16 @@ Ansible has a dynamic inventory plugin that can list your resources.
|
|||
You need to open an account and log into it before you can get a token.
|
||||
You can find your token at the following page: `https://console.online.net/en/api/access <https://console.online.net/en/api/access>`_
|
||||
|
||||
3. You can test that your inventory is working by running: ``ansible-inventory -v -i online_inventory.yml --list``
|
||||
3. You can test that your inventory is working by running:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ ansible-inventory -v -i online_inventory.yml --list
|
||||
|
||||
|
||||
4. Now you can run your playbook or any other module with this inventory:
|
||||
|
||||
::
|
||||
.. code-block:: console
|
||||
|
||||
$ ansible all -i online_inventory.yml -m ping
|
||||
sd-96735 | SUCCESS => {
|
||||
|
|
|
@ -17,7 +17,7 @@ Prerequisites for using the rax modules are minimal. In addition to ansible its
|
|||
all of the modules require and are tested against pyrax 1.5 or higher.
|
||||
You'll need this Python module installed on the execution host.
|
||||
|
||||
pyrax is not currently available in many operating system
|
||||
``pyrax`` is not currently available in many operating system
|
||||
package repositories, so you will likely need to install it via pip:
|
||||
|
||||
.. code-block:: bash
|
||||
|
@ -55,7 +55,7 @@ The `rax.py` inventory script and all `rax` modules support a standard `pyrax` c
|
|||
username = myraxusername
|
||||
api_key = d41d8cd98f00b204e9800998ecf8427e
|
||||
|
||||
Setting the environment parameter RAX_CREDS_FILE to the path of this file will help Ansible find how to load
|
||||
Setting the environment parameter ``RAX_CREDS_FILE`` to the path of this file will help Ansible find how to load
|
||||
this information.
|
||||
|
||||
More information about this credentials file can be found at
|
||||
|
@ -163,7 +163,7 @@ In Ansible it is quite possible to use multiple dynamic inventory plugins along
|
|||
rax.py
|
||||
++++++
|
||||
|
||||
To use the rackspace dynamic inventory script, copy ``rax.py`` into your inventory directory and make it executable. You can specify a credentials file for ``rax.py`` utilizing the ``RAX_CREDS_FILE`` environment variable.
|
||||
To use the Rackspace dynamic inventory script, copy ``rax.py`` into your inventory directory and make it executable. You can specify a credentials file for ``rax.py`` utilizing the ``RAX_CREDS_FILE`` environment variable.
|
||||
|
||||
.. note:: Dynamic inventory scripts (like ``rax.py``) are saved in ``/usr/share/ansible/inventory`` if Ansible has been installed globally. If installed to a virtualenv, the inventory scripts are installed to ``$VIRTUALENV/share/inventory``.
|
||||
|
||||
|
|
|
@ -3,7 +3,7 @@ Vultr Guide
|
|||
|
||||
Ansible offers a set of modules to interact with `Vultr <https://www.vultr.com>`_ cloud platform.
|
||||
|
||||
This set of module forms a framework that allows one to easily manage and orchestrate one's infratructure on Vultr cloud platform.
|
||||
This set of module forms a framework that allows one to easily manage and orchestrate one's infrastructure on Vultr cloud platform.
|
||||
|
||||
|
||||
Requirements
|
||||
|
@ -38,7 +38,7 @@ Ini file are structured this way:
|
|||
timeout = 30
|
||||
|
||||
|
||||
If ``VULTR_API_ACCOUNT`` enviroment variable or ``api_account`` module parameter is not specified, modules will look for the section named "default".
|
||||
If ``VULTR_API_ACCOUNT`` environment variable or ``api_account`` module parameter is not specified, modules will look for the section named "default".
|
||||
|
||||
|
||||
Authentication
|
||||
|
@ -110,7 +110,7 @@ Dynamic Inventory
|
|||
Ansible provides a dynamic inventory plugin for `Vultr <https://www.vultr.com>`_.
|
||||
The configuration process is exactly the same as the one for the modules.
|
||||
|
||||
To be able to use it one needs to enable it first by specifying the following in the ``ansible.cfg`` file:
|
||||
To be able to use it you need to enable it first by specifying the following in the ``ansible.cfg`` file:
|
||||
|
||||
.. code-block:: ini
|
||||
|
||||
|
@ -128,10 +128,10 @@ To list the available hosts one can simply run:
|
|||
|
||||
.. code-block:: console
|
||||
|
||||
#> ansible-inventory - i vultr.yml
|
||||
#> ansible-inventory -i vultr.yml --list
|
||||
|
||||
|
||||
This allows one - for example - to take action on nodes grouped by location or OS name:
|
||||
For example, this allows you to take action on nodes grouped by location or OS name:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
|
@ -141,4 +141,3 @@ This allows one - for example - to take action on nodes grouped by location or O
|
|||
- name: Rebooting the machine
|
||||
shell: reboot
|
||||
become: True
|
||||
|
||||
|
|
|
@ -274,7 +274,7 @@ def mandatory(a):
|
|||
name = "'%s' " % to_text(a._undefined_name)
|
||||
else:
|
||||
name = ''
|
||||
raise AnsibleFilterError("Mandatory variable %snot defined." % name)
|
||||
raise AnsibleFilterError("Mandatory variable %s not defined." % name)
|
||||
return a
|
||||
|
||||
|
||||
|
|
Loading…
Reference in a new issue