diff --git a/docs/docsite/rst/scenario_guides/guide_azure.rst b/docs/docsite/rst/scenario_guides/guide_azure.rst index c60ec334259..41bdab3c24f 100644 --- a/docs/docsite/rst/scenario_guides/guide_azure.rst +++ b/docs/docsite/rst/scenario_guides/guide_azure.rst @@ -77,20 +77,20 @@ order of precedence is parameters, then environment variables, and finally a fil Using Environment Variables ``````````````````````````` -To pass service principal credentials via the environment, define the following variables: +To pass service principal credentials through the environment, define the following variables: * AZURE_CLIENT_ID * AZURE_SECRET * AZURE_SUBSCRIPTION_ID * AZURE_TENANT -To pass Active Directory username/password via the environment, define the following variables: +To pass Active Directory username/password through the environment, define the following variables: * AZURE_AD_USER * AZURE_PASSWORD * AZURE_SUBSCRIPTION_ID -To pass Active Directory username/password in ADFS via the environment, define the following variables: +To pass Active Directory username/password in ADFS through the environment, define the following variables: * AZURE_AD_USER * AZURE_PASSWORD @@ -478,7 +478,7 @@ Disabling certificate validation on Azure endpoints When an HTTPS proxy is present, or when using Azure Stack, it may be necessary to disable certificate validation for Azure endpoints in the Azure modules. This is not a recommended security practice, but may be necessary when the system CA store cannot be altered to include the necessary CA certificate. Certificate validation can be controlled by setting -the "cert_validation_mode" value in a credential profile, via the "AZURE_CERT_VALIDATION_MODE" environment variable, or +the "cert_validation_mode" value in a credential profile, through the "AZURE_CERT_VALIDATION_MODE" environment variable, or by passing the "cert_validation_mode" argument to any Azure module. The default value is "validate"; setting the value to "ignore" will prevent all certificate validation. The module argument takes precedence over a credential profile value, which takes precedence over the environment value. diff --git a/docs/docsite/rst/scenario_guides/guide_packet.rst b/docs/docsite/rst/scenario_guides/guide_packet.rst index 08ae6552238..512620c2454 100644 --- a/docs/docsite/rst/scenario_guides/guide_packet.rst +++ b/docs/docsite/rst/scenario_guides/guide_packet.rst @@ -5,7 +5,7 @@ Packet.net Guide Introduction ============ -`Packet.net `_ is a bare metal infrastructure host that's supported by Ansible (>=2.3) via a dynamic inventory script and two cloud modules. The two modules are: +`Packet.net `_ is a bare metal infrastructure host that's supported by Ansible (>=2.3) through a dynamic inventory script and two cloud modules. The two modules are: - packet_sshkey: adds a public SSH key from file or value to the Packet infrastructure. Every subsequently-created device will have this public key installed in .ssh/authorized_keys. - packet_device: manages servers on Packet. You can use this module to create, restart and delete devices. @@ -21,9 +21,9 @@ The Packet modules and inventory script connect to the Packet API using the pack $ pip install packet-python -In order to check the state of devices created by Ansible on Packet, it's a good idea to install one of the `Packet CLI clients `_. Otherwise you can check them via the `Packet portal `_. +In order to check the state of devices created by Ansible on Packet, it's a good idea to install one of the `Packet CLI clients `_. Otherwise you can check them through the `Packet portal `_. -To use the modules and inventory script you'll need a Packet API token. You can generate an API token via the Packet portal `here `__. The simplest way to authenticate yourself is to set the Packet API token in an environment variable: +To use the modules and inventory script you'll need a Packet API token. You can generate an API token through the Packet portal `here `__. The simplest way to authenticate yourself is to set the Packet API token in an environment variable: .. code-block:: bash @@ -31,7 +31,7 @@ To use the modules and inventory script you'll need a Packet API token. You can If you're not comfortable exporting your API token, you can pass it as a parameter to the modules. -On Packet, devices and reserved IP addresses belong to `projects `_. In order to use the packet_device module, you need to specify the UUID of the project in which you want to create or manage devices. You can find a project's UUID in the Packet portal `here `_ (it's just under the project table) or via one of the available `CLIs `_. +On Packet, devices and reserved IP addresses belong to `projects `_. In order to use the packet_device module, you need to specify the UUID of the project in which you want to create or manage devices. You can find a project's UUID in the Packet portal `here `_ (it's just under the project table) or through one of the available `CLIs `_. If you want to use a new SSH key pair in this tutorial, you can generate it to ``./id_rsa`` and ``./id_rsa.pub`` as: @@ -46,7 +46,7 @@ If you want to use an existing key pair, just copy the private and public key ov Device Creation =============== -The following code block is a simple playbook that creates one `Type 0 `_ server (the 'plan' parameter). You have to supply 'plan' and 'operating_system'. 'location' defaults to 'ewr1' (Parsippany, NJ). You can find all the possible values for the parameters via a `CLI client `_. +The following code block is a simple playbook that creates one `Type 0 `_ server (the 'plan' parameter). You have to supply 'plan' and 'operating_system'. 'location' defaults to 'ewr1' (Parsippany, NJ). You can find all the possible values for the parameters through a `CLI client `_. .. code-block:: yaml @@ -67,7 +67,7 @@ The following code block is a simple playbook that creates one `Type 0 `__. +After running ``ansible-playbook playbook_create.yml``, you should have a server provisioned on Packet. You can verify through a CLI or in the `Packet portal `__. If you get an error with the message "failed to set machine state present, error: Error 404: Not Found", please verify your project UUID. @@ -183,7 +183,7 @@ The following playbook will create an SSH key, 3 Packet servers, and then wait u As with most Ansible modules, the default states of the Packet modules are idempotent, meaning the resources in your project will remain the same after re-runs of a playbook. Thus, we can keep the ``packet_sshkey`` module call in our playbook. If the public key is already in your Packet account, the call will have no effect. -The second module call provisions 3 Packet Type 0 (specified using the 'plan' parameter) servers in the project identified via the 'project_id' parameter. The servers are all provisioned with CoreOS beta (the 'operating_system' parameter) and are customized with cloud-config user data passed to the 'user_data' parameter. +The second module call provisions 3 Packet Type 0 (specified using the 'plan' parameter) servers in the project identified by the 'project_id' parameter. The servers are all provisioned with CoreOS beta (the 'operating_system' parameter) and are customized with cloud-config user data passed to the 'user_data' parameter. The ``packet_device`` module has a ``wait_for_public_IPv`` that is used to specify the version of the IP address to wait for (valid values are ``4`` or ``6`` for IPv4 or IPv6). If specified, Ansible will wait until the GET API call for a device contains an Internet-routeable IP address of the specified version. When referring to an IP address of a created device in subsequent module calls, it's wise to use the ``wait_for_public_IPv`` parameter, or ``state: active`` in the packet_device module call. @@ -193,7 +193,7 @@ Run the playbook: $ ansible-playbook playbook_coreos.yml -Once the playbook quits, your new devices should be reachable via SSH. Try to connect to one and check if etcd has started properly: +Once the playbook quits, your new devices should be reachable through SSH. Try to connect to one and check if etcd has started properly: .. code-block:: bash diff --git a/docs/docsite/rst/scenario_guides/guide_rax.rst b/docs/docsite/rst/scenario_guides/guide_rax.rst index 706115e3bbd..439ba187250 100644 --- a/docs/docsite/rst/scenario_guides/guide_rax.rst +++ b/docs/docsite/rst/scenario_guides/guide_rax.rst @@ -18,7 +18,7 @@ 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 -package repositories, so you will likely need to install it via pip: +package repositories, so you will likely need to install it through pip: .. code-block:: bash @@ -69,7 +69,7 @@ Running from a Python Virtual Environment (Optional) Most users will not be using virtualenv, but some users, particularly Python developers sometimes like to. -There are special considerations when Ansible is installed to a Python virtualenv, rather than the default of installing at a global scope. Ansible assumes, unless otherwise instructed, that the python binary will live at /usr/bin/python. This is done via the interpreter line in modules, however when instructed by setting the inventory variable 'ansible_python_interpreter', Ansible will use this specified path instead to find Python. This can be a cause of confusion as one may assume that modules running on 'localhost', or perhaps running via 'local_action', are using the virtualenv Python interpreter. By setting this line in the inventory, the modules will execute in the virtualenv interpreter and have available the virtualenv packages, specifically pyrax. If using virtualenv, you may wish to modify your localhost inventory definition to find this location as follows: +There are special considerations when Ansible is installed to a Python virtualenv, rather than the default of installing at a global scope. Ansible assumes, unless otherwise instructed, that the python binary will live at /usr/bin/python. This is done through the interpreter line in modules, however when instructed by setting the inventory variable 'ansible_python_interpreter', Ansible will use this specified path instead to find Python. This can be a cause of confusion as one may assume that modules running on 'localhost', or perhaps running through 'local_action', are using the virtualenv Python interpreter. By setting this line in the inventory, the modules will execute in the virtualenv interpreter and have available the virtualenv packages, specifically pyrax. If using virtualenv, you may wish to modify your localhost inventory definition to find this location as follows: .. code-block:: ini @@ -154,7 +154,7 @@ to the next section. Host Inventory `````````````` -Once your nodes are spun up, you'll probably want to talk to them again. The best way to handle this is to use the "rax" inventory plugin, which dynamically queries Rackspace Cloud and tells Ansible what nodes you have to manage. You might want to use this even if you are spinning up cloud instances via other tools, including the Rackspace Cloud user interface. The inventory plugin can be used to group resources by metadata, region, OS, and so on. Utilizing metadata is highly recommended in "rax" and can provide an easy way to sort between host groups and roles. If you don't want to use the ``rax.py`` dynamic inventory script, you could also still choose to manually manage your INI inventory file, though this is less recommended. +Once your nodes are spun up, you'll probably want to talk to them again. The best way to handle this is to use the "rax" inventory plugin, which dynamically queries Rackspace Cloud and tells Ansible what nodes you have to manage. You might want to use this even if you are spinning up cloud instances through other tools, including the Rackspace Cloud user interface. The inventory plugin can be used to group resources by metadata, region, OS, and so on. Utilizing metadata is highly recommended in "rax" and can provide an easy way to sort between host groups and roles. If you don't want to use the ``rax.py`` dynamic inventory script, you could also still choose to manually manage your INI inventory file, though this is less recommended. In Ansible it is quite possible to use multiple dynamic inventory plugins along with INI file data. Just put them in a common directory and be sure the scripts are chmod +x, and the INI-based ones are not. diff --git a/docs/docsite/rst/scenario_guides/guide_scaleway.rst b/docs/docsite/rst/scenario_guides/guide_scaleway.rst index ba399049e65..0baf58a5e26 100644 --- a/docs/docsite/rst/scenario_guides/guide_scaleway.rst +++ b/docs/docsite/rst/scenario_guides/guide_scaleway.rst @@ -9,7 +9,7 @@ Scaleway Guide Introduction ============ -`Scaleway `_ is a cloud provider supported by Ansible, version 2.6 or higher via a dynamic inventory plugin and modules. +`Scaleway `_ is a cloud provider supported by Ansible, version 2.6 or higher through a dynamic inventory plugin and modules. Those modules are: - :ref:`scaleway_sshkey_module`: adds a public SSH key from a file or value to the Packet infrastructure. Every subsequently-created device will have this public key installed in .ssh/authorized_keys. @@ -27,7 +27,7 @@ Requirements The Scaleway modules and inventory script connect to the Scaleway API using `Scaleway REST API `_. To use the modules and inventory script you'll need a Scaleway API token. -You can generate an API token via the Scaleway console `here `__. +You can generate an API token through the Scaleway console `here `__. The simplest way to authenticate yourself is to set the Scaleway API token in an environment variable: .. code-block:: bash