diff --git a/docs/docsite/rst/community/committer_guidelines.rst b/docs/docsite/rst/community/committer_guidelines.rst index 5c83718c3e9..3218cc846ab 100644 --- a/docs/docsite/rst/community/committer_guidelines.rst +++ b/docs/docsite/rst/community/committer_guidelines.rst @@ -10,12 +10,12 @@ These guidelines apply to everyone. At the same time, this ISN'T a process docum That said, use the trust wisely. -If you abuse the trust and break components and builds, etc., the trust level falls and you may be asked not to commit or you may lose your commit privileges. +If you abuse the trust and break components and builds, and so on, the trust level falls and you may be asked not to commit or you may lose your commit privileges. Features, high-level design, and roadmap ======================================== -As a core team member, you are an integral part of the team that develops the :ref:`roadmap `. Please be engaged, and push for the features and fixes that you want to see. Also keep in mind that Red Hat, as a company, will commit to certain features, fixes, APIs, etc. for various releases. Red Hat, the company, and the Ansible team must get these committed features (etc.) completed and released as scheduled. Obligations to users, the community, and customers must come first. Because of these commitments, a feature you want to develop yourself may not get into a release if it impacts a lot of other parts within Ansible. +As a core team member, you are an integral part of the team that develops the :ref:`roadmap `. Please be engaged, and push for the features and fixes that you want to see. Also keep in mind that Red Hat, as a company, will commit to certain features, fixes, APIs, and so on. for various releases. Red Hat, the company, and the Ansible team must get these committed features (and so on.) completed and released as scheduled. Obligations to users, the community, and customers must come first. Because of these commitments, a feature you want to develop yourself may not get into a release if it impacts a lot of other parts within Ansible. Any other new features and changes to high level design should go through the proposal process (TBD), to ensure the community and core team have had a chance to review the idea and approve it. The core team has sole responsibility for merging new features based on proposals. @@ -38,7 +38,7 @@ The Core Team is aware that this can be a difficult process at times. Sometimes, Roles on Core ============= * Core committers: Fine to do PRs for most things, but we should have a timebox. Hanging PRs may merge on the judgement of these devs. -* :ref:`Module maintainers `: Module maintainers own specific modules and have indirect commit access via the current module PR mechanisms. +* :ref:`Module maintainers `: Module maintainers own specific modules and have indirect commit access through the current module PR mechanisms. General rules ============= @@ -49,7 +49,7 @@ Individuals with direct commit access to ansible/ansible are entrusted with powe - Commit directly. - Merge your own PRs. Someone else should have a chance to review and approve the PR merge. If you are a Core Committer, you have a small amount of leeway here for very minor changes. - Forget about alternate environments. Consider the alternatives--yes, people have bad environments, but they are the ones who need us the most. - - Drag your community team members down. Always discuss the technical merits, but you should never address the person's limitations (you can later go for beers and call them idiots, but not in IRC/GitHub/etc.). + - Drag your community team members down. Always discuss the technical merits, but you should never address the person's limitations (you can later go for beers and call them idiots, but not in IRC/GitHub/and so on.). - Forget about the maintenance burden. Some things are really cool to have, but they might not be worth shoehorning in if the maintenance burden is too great. - Break playbooks. Always keep backwards compatibility in mind. - Forget to keep it simple. Complexity breeds all kinds of problems. @@ -57,11 +57,11 @@ Individuals with direct commit access to ansible/ansible are entrusted with powe * Do - Squash, avoid merges whenever possible, use GitHub's squash commits or cherry pick if needed (bisect thanks you). - - Be active. Committers who have no activity on the project (through merges, triage, commits, etc.) will have their permissions suspended. + - Be active. Committers who have no activity on the project (through merges, triage, commits, and so on.) will have their permissions suspended. - Consider backwards compatibility (goes back to "don't break existing playbooks"). - Write tests. PRs with tests are looked at with more priority than PRs without tests that should have them included. While not all changes require tests, be sure to add them for bug fixes or functionality changes. - Discuss with other committers, specially when you are unsure of something. - - Document! If your PR is a new feature or a change to behavior, make sure you've updated all associated documentation or have notified the right people to do so. It also helps to add the version of Core against which this documentation is compatible (to avoid confusion with stable versus devel docs, for backwards compatibility, etc.). + - Document! If your PR is a new feature or a change to behavior, make sure you've updated all associated documentation or have notified the right people to do so. It also helps to add the version of Core against which this documentation is compatible (to avoid confusion with stable versus devel docs, for backwards compatibility, and so on.). - Consider scope, sometimes a fix can be generalized - Keep it simple, then things are maintainable, debuggable and intelligible. @@ -71,7 +71,7 @@ Committers are expected to continue to follow the same community and contributio People ====== -Individuals who've been asked to become a part of this group have generally been contributing in significant ways to the Ansible community for some time. Should they agree, they are requested to add their names and GitHub IDs to this file, in the section below, via a pull request. Doing so indicates that these individuals agree to act in the ways that their fellow committers trust that they will act. +Individuals who've been asked to become a part of this group have generally been contributing in significant ways to the Ansible community for some time. Should they agree, they are requested to add their names and GitHub IDs to this file, in the section below, through a pull request. Doing so indicates that these individuals agree to act in the ways that their fellow committers trust that they will act. +---------------------+----------------------+--------------------+----------------------+ | Name | GitHub ID | IRC Nick | Other | diff --git a/docs/docsite/rst/community/communication.rst b/docs/docsite/rst/community/communication.rst index b19c3ec02b7..9f6f3325351 100644 --- a/docs/docsite/rst/community/communication.rst +++ b/docs/docsite/rst/community/communication.rst @@ -22,7 +22,7 @@ Ansible has several mailing lists. Your first post to the mailing list will be * `Ansible Container List `_ is for users and developers of the Ansible Container project. * `Ansible Development List `_ is for learning how to develop on Ansible, asking about prospective feature design, or discussions about extending ansible or features in progress. * `Ansible Lockdown List `_ is for all things related to Ansible Lockdown projects, including DISA STIG automation and CIS Benchmarks. -* `Ansible Outreach List `_ help with promoting Ansible and `Ansible Meetups `_ +* `Ansible Outreach List `_ help with promoting Ansible and `Ansible Meetups `_ * `Ansible Project List `_ is for sharing Ansible tips, answering questions, and general user discussion. * `Molecule List `_ is designed to aid with the development and testing of Ansible roles with Molecule. diff --git a/docs/docsite/rst/community/development_process.rst b/docs/docsite/rst/community/development_process.rst index 985454f0d12..d2630377f7e 100644 --- a/docs/docsite/rst/community/development_process.rst +++ b/docs/docsite/rst/community/development_process.rst @@ -27,7 +27,7 @@ If you want to follow the conversation about what features will be added to Ansi Micro development: the lifecycle of a PR ======================================== -Ansible accepts code via **pull requests** ("PRs" for short). GitHub provides a great overview of `how the pull request process works `_ in general. The ultimate goal of any pull request is to get merged and become part of Ansible Core. +Ansible accepts code through **pull requests** ("PRs" for short). GitHub provides a great overview of `how the pull request process works `_ in general. The ultimate goal of any pull request is to get merged and become part of Ansible Core. Here's an overview of the PR lifecycle: * Contributor opens a PR @@ -107,7 +107,7 @@ Information labels - **feature_pull_request**: applied by the bot based on the templatized description of the PR. - **networking**: applied by the bot based on the paths of the modified files. - **owner_pr**: largely deprecated. Formerly workflow, now informational. Originally, PRs submitted by the maintainer would automatically go to **shipit** based on this label. If the submitter is also a maintainer, we notify the other maintainers and still require one of the maintainers (including the submitter) to give a **shipit**. -- **pending_action**: applied by the bot to PRs that are not moving. Reviewed every couple of weeks by the community team, who tries to figure out the appropriate action (closure, asking for new maintainers, etc). +- **pending_action**: applied by the bot to PRs that are not moving. Reviewed every couple of weeks by the community team, who tries to figure out the appropriate action (closure, asking for new maintainers, and so on). Special Labels @@ -164,7 +164,7 @@ an existing one, so we can trace the change back to the PR that introduced it. To create a changelog entry, create a new file with a unique name in the ``changelogs/fragments/`` directory. The file name should include the PR number and a description of the change. It must end with the file extension ``.yaml``. For example: ``40696-user-backup-shadow-file.yaml`` A single changelog fragment may contain multiple sections but most will only contain one section. -The toplevel keys (bugfixes, major_changes, etc) are defined in the +The toplevel keys (bugfixes, major_changes, and so on) are defined in the `config file `_ for our release note tool. Here are the valid sections and a description of each: **major_changes** diff --git a/docs/docsite/rst/community/documentation_contributions.rst b/docs/docsite/rst/community/documentation_contributions.rst index 41bca638372..e7229810f81 100644 --- a/docs/docsite/rst/community/documentation_contributions.rst +++ b/docs/docsite/rst/community/documentation_contributions.rst @@ -49,7 +49,7 @@ A great documentation GitHub issue or PR includes: - a specific title - a detailed description of the problem (even for a PR - it's hard to evaluate a suggested change unless we know what problem it's meant to solve) -- links to other information (related issues/PRs, external documentation, pages on docs.ansible.com, etc.) +- links to other information (related issues/PRs, external documentation, pages on docs.ansible.com, and so on.) Before you open a complex documentation PR ========================================== diff --git a/docs/docsite/rst/community/index.rst b/docs/docsite/rst/community/index.rst index 26f3534ca37..2afd006cb72 100644 --- a/docs/docsite/rst/community/index.rst +++ b/docs/docsite/rst/community/index.rst @@ -36,7 +36,7 @@ Going deeper * I think Ansible is broken. How do I :ref:`report a bug `? * I need functionality that Ansible doesn't offer. How do I :ref:`request a feature `? * I'm waiting for a particular feature. How do I see what's :ref:`planned for future Ansible Releases `? -* I have a specific Ansible interest or expertise (for example, VMware, Linode, etc.). How do I get involved in a :ref:`working group `? +* I have a specific Ansible interest or expertise (for example, VMware, Linode, and so on.). How do I get involved in a :ref:`working group `? * I'd like to participate in conversations about features and fixes. How do I review GitHub issues and pull requests? * I found a typo or another problem on docs.ansible.com. How can I :ref:`improve the documentation `? diff --git a/docs/docsite/rst/community/maintainers.rst b/docs/docsite/rst/community/maintainers.rst index 631e19a9a3d..94e4acc0da8 100644 --- a/docs/docsite/rst/community/maintainers.rst +++ b/docs/docsite/rst/community/maintainers.rst @@ -42,7 +42,7 @@ Issues Issues for modules, including bug reports, documentation bug reports, and feature requests, are tracked in the `ansible repository `_. -Issues for modules are routed to their maintainers via an automated process. This process is still being refined, and currently depends upon the issue creator to provide adequate details (specifically, providing the proper module name) in order to route it correctly. If you are a maintainer of a specific module, it is recommended that you periodically search module issues for issues which mention your module's name (or some variation on that name), as well as setting an appropriate notification process for receiving notification of mentions of your GitHub ID. +Issues for modules are routed to their maintainers by an automated process. This process is still being refined, and currently depends upon the issue creator to provide adequate details (specifically, providing the proper module name) in order to route it correctly. If you are a maintainer of a specific module, it is recommended that you periodically search module issues for issues which mention your module's name (or some variation on that name), as well as setting an appropriate notification process for receiving notification of mentions of your GitHub ID. PR workflow ----------- diff --git a/docs/docsite/rst/community/other_tools_and_programs.rst b/docs/docsite/rst/community/other_tools_and_programs.rst index 06c21303e41..c7cc6c5bad3 100644 --- a/docs/docsite/rst/community/other_tools_and_programs.rst +++ b/docs/docsite/rst/community/other_tools_and_programs.rst @@ -59,7 +59,7 @@ Visual Studio Code An open-source, free GUI text editor created and maintained by Microsoft. Useful Visual Studio Code plugins include: -* `YAML Support by Red Hat `_ - provides YAML support via yaml-language-server with built-in Kubernetes and Kedge syntax support. +* `YAML Support by Red Hat `_ - provides YAML support through yaml-language-server with built-in Kubernetes and Kedge syntax support. * `Ansible Syntax Highlighting Extension `_ - YAML & Jinja2 support. * `Visual Studio Code extension for Ansible `_ - provides autocompletion, syntax highlighting. @@ -103,7 +103,7 @@ Other Tools - `Ansible Inventory Grapher `_ - visually displays inventory inheritance hierarchies and at what level a variable is defined in inventory. - `Ansible Playbook Grapher `_ - A command line tool to create a graph representing your Ansible playbook tasks and roles. - `Ansible Shell `_ - an interactive shell for Ansible with built-in tab completion for all the modules. -- `Ansible Silo `_ - a self-contained Ansible environment via Docker. +- `Ansible Silo `_ - a self-contained Ansible environment by Docker. - `Ansigenome `_ - a command line tool designed to help you manage your Ansible roles. - `ARA `_ - records Ansible playbook runs and makes the recorded data available and intuitive for users and systems by integrating with Ansible as a callback plugin. - `Awesome Ansible `_ - a collaboratively curated list of awesome Ansible resources. diff --git a/docs/docsite/rst/community/reporting_bugs_and_features.rst b/docs/docsite/rst/community/reporting_bugs_and_features.rst index bcd222b998b..d55ea995a1a 100644 --- a/docs/docsite/rst/community/reporting_bugs_and_features.rst +++ b/docs/docsite/rst/community/reporting_bugs_and_features.rst @@ -21,7 +21,7 @@ Knowing your Ansible version and the exact commands you are running, and what yo Do not use the issue tracker for "how do I do this" type questions. These are great candidates for IRC or the mailing list instead where things are likely to be more of a discussion. -To be respectful of reviewers' time and allow us to help everyone efficiently, please provide minimal well-reduced and well-commented examples versus sharing your entire production playbook. Include playbook snippets and output where possible. +To be respectful of reviewers' time and allow us to help everyone efficiently, please provide minimal well-reduced and well-commented examples rather than sharing your entire production playbook. Include playbook snippets and output where possible. When sharing YAML in playbooks, formatting can be preserved by using `code blocks `_. diff --git a/docs/docsite/rst/dev_guide/developing_collections.rst b/docs/docsite/rst/dev_guide/developing_collections.rst index eb3c61764be..70e8091d590 100644 --- a/docs/docsite/rst/dev_guide/developing_collections.rst +++ b/docs/docsite/rst/dev_guide/developing_collections.rst @@ -13,6 +13,8 @@ You can publish and use collections through `Ansible Galaxy `_ for an example of a full collection structure. * Not all directories are currently in use. Those are placeholders for future features. +.. _galaxy_yml: galaxy.yml ---------- @@ -52,6 +55,7 @@ galaxy.yml A collection must have a ``galaxy.yml`` file that contains the necessary information to build a collection artifact. See :ref:`collections_galaxy_meta` for details. +.. _collections_doc_dir: docs directory --------------- @@ -68,11 +72,14 @@ The ``ansible-doc`` command requires the fully qualified collection name (FQCN) .. note:: The Ansible collection namespace is defined in the ``galaxy.yml`` file and is not equivalent to the GitHub repository name. +.. _collections_plugin_dir: plugins directory ------------------ -Add a 'per plugin type' specific subdirectory here, including ``module_utils`` which is usable not only by modules, but by any other plugin by using their FQCN. This is a way to distribute modules, lookups, filters, and so on, without having to import a role in every play. +Add a 'per plugin type' specific subdirectory here, including ``module_utils`` which is usable not only by modules, but by most plugins by using their FQCN. This is a way to distribute modules, lookups, filters, and so on, without having to import a role in every play. + +Vars plugins are unsupported in collections. Cache plugins may be used in collections for fact caching, but are not supported for inventory plugins. module_utils ^^^^^^^^^^^^ @@ -109,6 +116,11 @@ In the Python example the ``module_util`` in question is called ``qradar`` such not_rest_data_keys=['state'] ) +Note that importing something from an ``__init__.py`` file requires using the file name: + +.. code-block:: python + + from ansible_collections.namespace.collection_name.plugins.callback.__init__ import CustomBaseClass In the PowerShell example the ``module_util`` in question is called ``hyperv`` such that the FCQN is ``ansible_example.community.plugins.module_utils.hyperv``: @@ -129,6 +141,7 @@ In the PowerShell example the ``module_util`` in question is called ``hyperv`` s $module.ExitJson() +.. _collections_roles_dir: roles directory ---------------- @@ -255,6 +268,8 @@ You can publish collections to Galaxy using the ``ansible-galaxy collection publ .. note:: Once you upload a version of a collection, you cannot delete or modify that version. Ensure that everything looks okay before you upload it. +.. _upload_collection_ansible_galaxy: + Upload using ansible-galaxy ^^^^^^^^^^^^^^^^^^^^^^^^^^^ @@ -272,8 +287,10 @@ without waiting for the import result, use the ``--no-wait`` argument and manual The API key is a secret token used by Ansible Galaxy to protect your content. You can find your API key at your `Galaxy profile preferences `_ page. -Upload from the Galaxy website -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +.. _upload_collection_galaxy: + +Upload a collection from the Galaxy website +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ To upload your collection artifact directly on Galaxy: @@ -287,6 +304,7 @@ namespace, the upload request will fail. Once Galaxy uploads and accepts a collection, you will be redirected to the **My Imports** page, which displays output from the import process, including any errors or warnings about the metadata and content contained in the collection. +.. _collection_versions: Collection versions ------------------- @@ -301,6 +319,8 @@ Collection versions use `Sematic Versioning `_ for version * Increment minor (for example: y in `x.y.z`) version number for new functionality in a backwards compatible manner. * Increment patch (for example: z in `x.y.z`) version number for backwards compatible bug fixes. +.. _migrate_to_collection: + Migrating Ansible content to a collection ========================================= diff --git a/docs/docsite/rst/dev_guide/developing_inventory.rst b/docs/docsite/rst/dev_guide/developing_inventory.rst index 13c880f1847..e93787014f8 100644 --- a/docs/docsite/rst/dev_guide/developing_inventory.rst +++ b/docs/docsite/rst/dev_guide/developing_inventory.rst @@ -74,6 +74,8 @@ The first thing you want to do is use the base class: NAME = 'myplugin' # used internally by Ansible, it should match the file name but not required +If the inventory plugin is in a collection the NAME should be in the format of 'namespace.collection_name.myplugin'. + This class has a couple of methods each plugin should implement and a few helpers for parsing the inventory source and updating the inventory. After you have the basic plugin working you might want to to incorporate other features by adding more base classes: diff --git a/docs/docsite/rst/dev_guide/developing_modules_general_aci.rst b/docs/docsite/rst/dev_guide/developing_modules_general_aci.rst index 9a5b6935e42..c013197d6b1 100644 --- a/docs/docsite/rst/dev_guide/developing_modules_general_aci.rst +++ b/docs/docsite/rst/dev_guide/developing_modules_general_aci.rst @@ -325,7 +325,7 @@ You can test your ``construct_url()`` and ``payload()`` arguments without access import json from ansible.module_utils.network.aci.aci import ACIModule - # Just another class mimicking a bare AnsibleModule class for construct_url() and payload() methods + # Just another class mimicing a bare AnsibleModule class for construct_url() and payload() methods class AltModule(): params = dict( host='dummy', diff --git a/docs/docsite/rst/dev_guide/developing_plugins.rst b/docs/docsite/rst/dev_guide/developing_plugins.rst index 2bbfe0d2a3f..3c8c19d3339 100644 --- a/docs/docsite/rst/dev_guide/developing_plugins.rst +++ b/docs/docsite/rst/dev_guide/developing_plugins.rst @@ -150,7 +150,7 @@ see the source code for the `action plugins included with Ansible Core )``. If you import a cache plugin directly in the code base, you can only access options via ``ansible.constants``, and you break the cache plugin's ability to be used by an inventory plugin. @@ -246,7 +246,7 @@ but with an extra option so you can see how configuration works in Ansible versi """ CALLBACK_VERSION = 2.0 CALLBACK_TYPE = 'aggregate' - CALLBACK_NAME = 'timer' + CALLBACK_NAME = 'namespace.collection_name.timer' # only needed if you ship it and don't want to enable by default CALLBACK_NEEDS_WHITELIST = True @@ -320,7 +320,7 @@ Lookup plugins pull in data from external data stores. Lookup plugins can be use Lookup plugins are very flexible, allowing you to retrieve and return any type of data. When writing lookup plugins, always return data of a consistent type that can be easily consumed in a playbook. Avoid parameters that change the returned data type. If there is a need to return a single value sometimes and a complex dictionary other times, write two different lookup plugins. -Ansible includes many :ref:`filters ` which can be used to manipulate the data returned by a lookup plugin. Sometimes it makes sense to do the filtering inside the lookup plugin, other times it is better to return results that can be filtered in the playbook. Keep in mind how the data will be referenced when determing the appropriate level of filtering to be done inside the lookup plugin. +Ansible includes many :ref:`filters ` which can be used to manipulate the data returned by a lookup plugin. Sometimes it makes sense to do the filtering inside the lookup plugin, other times it is better to return results that can be filtered in the playbook. Keep in mind how the data will be referenced when determining the appropriate level of filtering to be done inside the lookup plugin. Here's a simple lookup plugin implementation --- this lookup returns the contents of a text file as a variable: @@ -389,7 +389,7 @@ The following is an example of how this lookup is called:: --- - hosts: all vars: - contents: "{{ lookup('file', '/etc/foo.txt') }}" + contents: "{{ lookup('namespace.collection_name.file', '/etc/foo.txt') }}" tasks: @@ -418,7 +418,7 @@ Vars plugins Vars plugins inject additional variable data into Ansible runs that did not come from an inventory source, playbook, or command line. Playbook constructs like 'host_vars' and 'group_vars' work using vars plugins. -Vars plugins were partially implemented in Ansible 2.0 and rewritten to be fully implemented starting with Ansible 2.4. +Vars plugins were partially implemented in Ansible 2.0 and rewritten to be fully implemented starting with Ansible 2.4. Vars plugins are unsupported by collections. Older plugins used a ``run`` method as their main body/work: diff --git a/docs/docsite/rst/dev_guide/developing_program_flow_modules.rst b/docs/docsite/rst/dev_guide/developing_program_flow_modules.rst index 6618bb4ceda..25600076485 100644 --- a/docs/docsite/rst/dev_guide/developing_program_flow_modules.rst +++ b/docs/docsite/rst/dev_guide/developing_program_flow_modules.rst @@ -620,7 +620,7 @@ no_log aliases """"""" -``aliases`` accepts a list of alternative argument names for the argument, such as the case where the argument is ``name`` but the module accepts ``aliases=['pkg']`` to allow ``pkg`` to be interchangably with ``name`` +``aliases`` accepts a list of alternative argument names for the argument, such as the case where the argument is ``name`` but the module accepts ``aliases=['pkg']`` to allow ``pkg`` to be interchangeably with ``name`` options """"""" diff --git a/docs/docsite/rst/dev_guide/platforms/aws_guidelines.rst b/docs/docsite/rst/dev_guide/platforms/aws_guidelines.rst index b68b045793a..c0d706ade07 100644 --- a/docs/docsite/rst/dev_guide/platforms/aws_guidelines.rst +++ b/docs/docsite/rst/dev_guide/platforms/aws_guidelines.rst @@ -347,7 +347,7 @@ API throttling (rate limiting) and pagination ============================================= For methods that return a lot of results, boto3 often provides -`paginators `_. If the method +`paginators `_. If the method you're calling has ``NextToken`` or ``Marker`` parameters, you should probably check whether a paginator exists (the top of each boto3 service reference page has a link to Paginators, if the service has any). To use paginators, obtain a paginator object, @@ -640,7 +640,7 @@ to your test in the following variables: * `security_token` So all invocations of AWS modules in the test should set these parameters. To avoid duplication these -for every call, it's preferable to use `YAML Anchors `_. For example: +for every call, it's preferable to use `YAML Anchors `_. For example: .. code-block:: yaml diff --git a/docs/docsite/rst/dev_guide/platforms/openstack_guidelines.rst b/docs/docsite/rst/dev_guide/platforms/openstack_guidelines.rst index 3417342f310..ac3f686f0c7 100644 --- a/docs/docsite/rst/dev_guide/platforms/openstack_guidelines.rst +++ b/docs/docsite/rst/dev_guide/platforms/openstack_guidelines.rst @@ -46,7 +46,7 @@ Libraries standard input such as auth and ssl support. * All modules should include ``extends_documentation_fragment: openstack``. * All complex cloud interaction or interoperability code should be housed in - the `openstacksdk `_ + the `openstacksdk `_ library. * All OpenStack API interactions should happen via the openstacksdk and not via OpenStack Client libraries. The OpenStack Client libraries do no have end diff --git a/docs/docsite/rst/dev_guide/platforms/ovirt_dev_guide.rst b/docs/docsite/rst/dev_guide/platforms/ovirt_dev_guide.rst index 56df1671436..3789c0e3033 100644 --- a/docs/docsite/rst/dev_guide/platforms/ovirt_dev_guide.rst +++ b/docs/docsite/rst/dev_guide/platforms/ovirt_dev_guide.rst @@ -44,7 +44,7 @@ Libraries along with ``ovirt_full_argument_spec``. - All info modules should use ``extends_documentation_fragment``: ``ovirt_info`` to go along with ``ovirt_info_full_argument_spec``. -- Functions that are common to all modules should be implemeneted in the +- Functions that are common to all modules should be implemented in the ``module_utils/ovirt.py`` file, so they can be reused. - Python SDK version 4 must be used. @@ -214,7 +214,7 @@ Testing ------- - Integration testing is currently done in oVirt's CI system - `on Jenkins `__ + `on Jenkins `__ and `on GitHub `__. - Please consider using these integration tests if you create a new module or add a new feature to an existing diff --git a/docs/docsite/rst/dev_guide/platforms/vmware_guidelines.rst b/docs/docsite/rst/dev_guide/platforms/vmware_guidelines.rst index ea3a3d2e6f8..948268bac64 100644 --- a/docs/docsite/rst/dev_guide/platforms/vmware_guidelines.rst +++ b/docs/docsite/rst/dev_guide/platforms/vmware_guidelines.rst @@ -89,7 +89,7 @@ Configure your installation Prepare a configuration file that describes your set-up. The file should be called :file:`test/integration/cloud-config-vcenter.ini` and based on -:file:`test/integration/cloud-config-vcenter.ini.template`. For instance, if you've deployed your lab with +:file:`test/lib/ansible_test/config/cloud-config-vcenter.ini.template`. For instance, if you've deployed your lab with `vmware-on-libvirt `: .. code-block:: ini diff --git a/docs/docsite/rst/dev_guide/style_guide/basic_rules.rst b/docs/docsite/rst/dev_guide/style_guide/basic_rules.rst index ff64564c7aa..eade01ec7d9 100644 --- a/docs/docsite/rst/dev_guide/style_guide/basic_rules.rst +++ b/docs/docsite/rst/dev_guide/style_guide/basic_rules.rst @@ -61,7 +61,7 @@ For menu procedures, bold the menu names, button names, etc to help the user fin 3. In the **Open** dialog box, click **Save**. 4. On the toolbar, click the **Open File** icon. -For code or command snippets, use the RST `code-block directive `_:: +For code or command snippets, use the RST `code-block directive `_:: .. code-block:: bash diff --git a/docs/docsite/rst/dev_guide/style_guide/index.rst b/docs/docsite/rst/dev_guide/style_guide/index.rst index 789c9d991d0..5a6a3532913 100644 --- a/docs/docsite/rst/dev_guide/style_guide/index.rst +++ b/docs/docsite/rst/dev_guide/style_guide/index.rst @@ -48,6 +48,30 @@ Header case Headers should be written in sentence case. For example, this section's title is ``Header case``, not ``Header Case`` or ``HEADER CASE``. + +Avoid using Latin phrases +------------------------- + +Latin words and phrases like ``e.g.`` or ``etc.`` +are easily understood by English speakers. +They may be harder to understand for others and are also tricky for automated translation. + +Use the following English terms in place of Latin terms or abbreviations: ++-------------------------------+------------------------------+ +| Latin | English | ++===============================+==============================+ +| i.e | in other words | ++-------------------------------+------------------------------+ +| e.g. | for example | ++-------------------------------+------------------------------+ +| etc | and so on | ++-------------------------------+------------------------------+ +| via | by/ through | ++-------------------------------+------------------------------+ +| vs./versus | rather than/against | ++-------------------------------+------------------------------+ + + reStructuredText guidelines =========================== @@ -57,7 +81,7 @@ We follow these technical or mechanical guidelines on all rST pages: Header notation --------------- -`Section headers in reStructuredText `_ +`Section headers in reStructuredText `_ can use a variety of notations. Sphinx will 'learn on the fly' when creating a hierarchy of headers. To make our documents easy to read and to edit, we follow a standard set of header notations. @@ -111,7 +135,7 @@ We use: Internal navigation ------------------- -`Anchors (also called labels) and links `_ +`Anchors (also called labels) and links `_ work together to help users find related content. Local tables of contents also help users navigate quickly to the information they need. All internal links should use the ``:ref:`` syntax. diff --git a/docs/docsite/rst/network/getting_started/network_resources.rst b/docs/docsite/rst/network/getting_started/network_resources.rst index 499697b7a8e..c0fbd7b2a9c 100644 --- a/docs/docsite/rst/network/getting_started/network_resources.rst +++ b/docs/docsite/rst/network/getting_started/network_resources.rst @@ -44,4 +44,4 @@ Join us on: * Freenode IRC - ``#ansible-network`` Freenode channel -* Slack - ``_ +* Slack - ``_ diff --git a/docs/docsite/rst/network/user_guide/platform_cnos.rst b/docs/docsite/rst/network/user_guide/platform_cnos.rst index 664d7924718..70201d7f382 100644 --- a/docs/docsite/rst/network/user_guide/platform_cnos.rst +++ b/docs/docsite/rst/network/user_guide/platform_cnos.rst @@ -65,7 +65,7 @@ Example CLI Task .. code-block:: yaml - - name: Retreive CNOS OS version + - name: Retrieve CNOS OS version cnos_command: commands: show version when: ansible_network_os == 'cnos' diff --git a/docs/docsite/rst/network/user_guide/platform_enos.rst b/docs/docsite/rst/network/user_guide/platform_enos.rst index 142ccf771c3..02f7386a7e2 100644 --- a/docs/docsite/rst/network/user_guide/platform_enos.rst +++ b/docs/docsite/rst/network/user_guide/platform_enos.rst @@ -67,7 +67,7 @@ Example CLI Task .. code-block:: yaml - - name: Retreive ENOS OS version + - name: Retrieve ENOS OS version enos_command: commands: show version when: ansible_network_os == 'enos' diff --git a/docs/docsite/rst/network/user_guide/platform_index.rst b/docs/docsite/rst/network/user_guide/platform_index.rst index 6083c25d2d3..cbbad65e28a 100644 --- a/docs/docsite/rst/network/user_guide/platform_index.rst +++ b/docs/docsite/rst/network/user_guide/platform_index.rst @@ -41,7 +41,7 @@ Settings by Platform .. raw:: html