diff --git a/.github/ISSUE_TEMPLATE.md b/.github/ISSUE_TEMPLATE.md index fbfae51022a..a6df6560cf0 100644 --- a/.github/ISSUE_TEMPLATE.md +++ b/.github/ISSUE_TEMPLATE.md @@ -13,7 +13,7 @@ Also test if the latest release, and master branch are affected too. ##### ANSIBLE VERSION - + ``` ``` @@ -27,7 +27,7 @@ Mention any settings you have changed/added/removed in ansible.cfg ##### OS / ENVIRONMENT diff --git a/.github/PULL_REQUEST_TEMPLATE.md b/.github/PULL_REQUEST_TEMPLATE.md index 13fc374ab78..a5adad7822d 100644 --- a/.github/PULL_REQUEST_TEMPLATE.md +++ b/.github/PULL_REQUEST_TEMPLATE.md @@ -18,7 +18,7 @@ the change does. ##### ANSIBLE VERSION - + ``` ``` diff --git a/CHANGELOG.md b/CHANGELOG.md index fc22e4f844a..17f15388df4 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -1838,7 +1838,7 @@ Module fixes: This re-executes inventory scripts, but does not force them to ignore any cache they might use. * New delegate_facts directive, a boolean that allows you to apply facts to the delegated host (true/yes) instead of the inventory_hostname (no/false) which is the default and previous behaviour. * local connections now work with 'su' as a privilege escalation method -* Ansible 2.0 has deprecated the “ssh” from ansible_ssh_user, ansible_ssh_host, and ansible_ssh_port to become ansible_user, ansible_host, and ansible_port. +* Ansible 2.0 has deprecated the "ssh" from ansible_ssh_user, ansible_ssh_host, and ansible_ssh_port to become ansible_user, ansible_host, and ansible_port. * New ssh configuration variables (`ansible_ssh_common_args`, `ansible_ssh_extra_args`) can be used to configure a per-group or per-host ssh ProxyCommand or set any other ssh options. `ansible_ssh_extra_args` is used to set options that are accepted only by ssh (not sftp or scp, which have their own analogous settings). diff --git a/docs/docsite/rst/committer_guidelines.rst b/docs/docsite/rst/committer_guidelines.rst index dd11a80d147..2b121c21a68 100644 --- a/docs/docsite/rst/committer_guidelines.rst +++ b/docs/docsite/rst/committer_guidelines.rst @@ -3,7 +3,7 @@ Committers Guidelines (for people with commit rights to Ansible on GitHub) These are the guidelines for people with commit access to Ansible. Committers are essentially acting as members of the Ansible Core team, although not necessarily as an employee of Ansible and Red Hat. Please read the guidelines before you commit. -These guidelines apply to everyone. At the same time, this ISN’T a process document. So just use good judgement. You’ve been given commit access because we trust your judgement. +These guidelines apply to everyone. At the same time, this ISN'T a process document. So just use good judgement. You've been given commit access because we trust your judgement. That said, use the trust wisely. @@ -19,18 +19,18 @@ Any other new features and changes to high level design should go through the pr Our Workflow on GitHub ====================== -As a committer, you may already know this, but our workflow forms a lot of our team policies. Please ensure you’re aware of the following workflow steps: +As a committer, you may already know this, but our workflow forms a lot of our team policies. Please ensure you're aware of the following workflow steps: * Fork the repository upon which you want to do some work to your own personal repository * Work on the specific branch upon which you need to commit -* Create a Pull Request back to the Ansible repository and tag the people you would like to review; assign someone as the primary “owner” of your request +* Create a Pull Request back to the Ansible repository and tag the people you would like to review; assign someone as the primary "owner" of your request * Adjust code as necessary based on the Comments provided * Ask someone on the Core Team to do a final review and merge Addendum to workflow for Committers: ------------------------------------ -The Core Team is aware that this can be a difficult process at times. Sometimes, the team breaks the rules: Direct commits, merging their own PRs. This section is a set of guidelines. If you’re changing a comma in a doc, or making a very minor change, you can use your best judgement. This is another trust thing. The process is critical for any major change, but for little things or getting something done quickly, use your best judgement and make sure people on the team are aware of your work. +The Core Team is aware that this can be a difficult process at times. Sometimes, the team breaks the rules: Direct commits, merging their own PRs. This section is a set of guidelines. If you're changing a comma in a doc, or making a very minor change, you can use your best judgement. This is another trust thing. The process is critical for any major change, but for little things or getting something done quickly, use your best judgement and make sure people on the team are aware of your work. Roles on Core ============= @@ -41,12 +41,12 @@ General Rules ============= Individuals with direct commit access to ansible/ansible are entrusted with powers that allow them to do a broad variety of things--probably more than we can write down. Rather than rules, treat these as general *guidelines*, individuals with this power are expected to use their best judgement. -* Don’t +* Don't - 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/etc.). - 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. @@ -55,7 +55,7 @@ Individuals with direct commit access to ansible/ansible are entrusted with powe - 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. - - Consider backwards compatibility (goes back to "don’t break existing playbooks"). + - 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.). diff --git a/docs/docsite/rst/community.rst b/docs/docsite/rst/community.rst index b011bd5f650..6b4f30f7732 100644 --- a/docs/docsite/rst/community.rst +++ b/docs/docsite/rst/community.rst @@ -2,7 +2,7 @@ Community Information & Contributing ```````````````````````````````````` Ansible is an open source project designed to bring together administrators and developers of all kinds to collaborate on building -IT automation solutions that work well for them. +IT automation solutions that work well for them. Should you wish to get more involved -- whether in terms of just asking a question, helping other users, introducing new people to Ansible, or helping with the software or documentation, we welcome your contributions to the project. @@ -16,7 +16,7 @@ I've Got A Question We're happy to help! -Ansible questions are best asked on the `Ansible Google Group Mailing List `_. +Ansible questions are best asked on the `Ansible Google Group Mailing List `_. This is a very large high-traffic list for answering questions and sharing tips and tricks. Anyone can join, and email delivery is optional if you just want to read the group online. To cut down on spam, your first post is moderated, though posts are approved quickly. @@ -42,10 +42,10 @@ This is a low-traffic read-only list, where we'll share release announcements an I'd Like To Help Share and Promote Ansible ------------------------------------------ -You can help share Ansible with others by telling friends and colleagues, writing a blog post, -or presenting at user groups (like DevOps groups or the local LUG). +You can help share Ansible with others by telling friends and colleagues, writing a blog post, +or presenting at user groups (like DevOps groups or the local LUG). -You are also welcome to share slides on speakerdeck, sign up for a free account and tag it “Ansible”. On Twitter, +You are also welcome to share slides on speakerdeck, sign up for a free account and tag it "Ansible". On Twitter, you can also share things with #ansible and may wish to `follow us `_. I'd Like To Help Ansible Move Faster @@ -73,31 +73,31 @@ more quickly. 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 +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. +playbook. Include playbook snippets and output where possible. When sharing YAML in playbooks, formatting can be preserved by using `code blocks `_. For multiple-file content, we encourage use of gist.github.com. Online pastebin content can expire, so it's nice to have things around for a longer term if they are referenced in a ticket. -If you are not sure if something is a bug yet, you are welcome to ask about something on -the mailing list or IRC first. +If you are not sure if something is a bug yet, you are welcome to ask about something on +the mailing list or IRC first. -As we are a very high volume project, if you determine that +As we are a very high volume project, if you determine that you do have a bug, please be sure to open the issue yourself to ensure we have a record of -it. Don’t rely on someone else in the community to file the bug report for you. +it. Don't rely on someone else in the community to file the bug report for you. It may take some time to get to your report, see our information about priority flags below. I'd Like To Help With Documentation ----------------------------------- -Ansible documentation is a community project too! +Ansible documentation is a community project too! -If you would like to help with the -documentation, whether correcting a typo or improving a section, or maybe even +If you would like to help with the +documentation, whether correcting a typo or improving a section, or maybe even documenting a new feature, submit a GitHub pull request to the code that lives in the ``docsite/rst`` subdirectory of the project for most pages, and there is an "Edit on GitHub" link up on those. @@ -107,9 +107,9 @@ Module documentation is generated from a ``DOCUMENTATION`` structure embedded in For more information on module documentation see `How to document modules `_. Aside from modules, the main docs are in restructured text -format. +format. -If you aren’t comfortable with restructured text, you can also open a ticket on +If you aren't comfortable with restructured text, you can also open a ticket on GitHub about any errors you spot or sections you would like to see added. For more information on creating pull requests, please refer to the `GitHub help guide `_. @@ -155,7 +155,7 @@ If you make a mistake you do not need to close your PR. Instead, create a clean with ``--force`` to overwrite the existing branch (permissible in this case as no one else should be using that branch as reference). Code comments won't be lost, they just won't be attached to the existing branch. -We’ll then review your contributions and engage with you about questions and so on. +We'll then review your contributions and engage with you about questions and so on. Because we have a very large and active community it may take awhile to get your contributions in! See the notes about priorities in a later section for understanding our work queue. @@ -172,7 +172,7 @@ are interested in writing new modules to be included in the core Ansible distrib to the `module development documentation `_. Ansible's aesthetic encourages simple, readable code and consistent, -conservatively extending, backwards-compatible improvements. When contributing code to Ansible, +conservatively extending, backwards-compatible improvements. When contributing code to Ansible, please observe the following guidelines: - Code developed for Ansible needs to support Python2-2.6 or higher and Python3-3.5 or higher. @@ -228,7 +228,7 @@ To subscribe to a group from a non-google account, you can send an email to the IRC Meetings ------------ -The Ansible community holds regular IRC meetings on various topics, and anyone who is interested is invited to +The Ansible community holds regular IRC meetings on various topics, and anyone who is interested is invited to participate. For more information about Ansible meetings, consult the `meeting schedule and agenda page `_. Release Numbering @@ -286,7 +286,7 @@ These labels don't really have a definition - they are a simple ordering. Howev affecting a major module (yum, apt, etc) is likely to be prioritized higher than a module affecting a smaller number of users. -Since we place a strong emphasis on testing and code review, it may take a few months for a minor feature to get merged. This doesn't mean that we'll be exhausting all of the higher-priority queues before getting to your ticket; we will also take periodic sweeps through the lower priority queues and give them some attention as well, particularly in the area of new module changes. +Since we place a strong emphasis on testing and code review, it may take a few months for a minor feature to get merged. This doesn't mean that we'll be exhausting all of the higher-priority queues before getting to your ticket; we will also take periodic sweeps through the lower priority queues and give them some attention as well, particularly in the area of new module changes. Every bit of effort helps - if you're wishing to expedite the inclusion of a P3 feature pull request for instance, the best thing you can do is help close P2 bug reports. diff --git a/docs/docsite/rst/community/development_process.rst b/docs/docsite/rst/community/development_process.rst index 050d8c9b9c8..da3a6fff68e 100644 --- a/docs/docsite/rst/community/development_process.rst +++ b/docs/docsite/rst/community/development_process.rst @@ -41,9 +41,9 @@ Each module has at least one assigned maintainer, listed in a `maintainer's file .. _Ansibullbot: https://github.com/ansible/ansibullbot/blob/master/ISSUE_HELP.md .. _maintainer's file: https://github.com/ansible/ansible/blob/devel/.github/BOTMETA.yml -Some modules have no community maintainers assigned. In this case, the maintainer is listed as ``$team_ansible``. Ultimately, it’s our goal to have at least one community maintainer for every module. +Some modules have no community maintainers assigned. In this case, the maintainer is listed as ``$team_ansible``. Ultimately, it's our goal to have at least one community maintainer for every module. -The maintainer’s job is to review PRs and decide whether that PR should be merged (``shipit``) or revised (``needs_revision``). +The maintainer's job is to review PRs and decide whether that PR should be merged (``shipit``) or revised (``needs_revision``). The ultimate goal of any pull request is to reach **shipit** status, where the Core team then decides whether the PR is ready to be merged. Not every PR that reaches the **shipit** label is actually ready to be merged, but the better our reviewers are, and the better our guidelines are, the more likely it will be that a PR that reaches **shipit** will be mergeable. @@ -54,7 +54,7 @@ Workflow Ansibullbot runs continuously. You can generally expect to see changes to your issue or pull request within thirty minutes. Ansibullbot examines every open pull request in the repositories, and enforces state roughly according to the following workflow: -- If a pull request has no workflow labels, it’s considered **new**. Files in the pull request are identified, and the maintainers of those files are pinged by the bot, along with instructions on how to review the pull request. (Note: sometimes we strip labels from a pull request to “reboot” this process.) +- If a pull request has no workflow labels, it's considered **new**. Files in the pull request are identified, and the maintainers of those files are pinged by the bot, along with instructions on how to review the pull request. (Note: sometimes we strip labels from a pull request to "reboot" this process.) - If the module maintainer is not ``$team_ansible``, the pull request then goes into the **community_review** state. - If the module maintainer is ``$team_ansible``, the pull request then goes into the **core_review** state (and probably sits for a while). - If the pull request is in **community_review** and has received comments from the maintainer: @@ -110,4 +110,4 @@ Special Labels - **new_plugin**: this is for new modules or plugins that are not yet in Ansible. - **Note:** `new_plugin` kicks off a completely separate process, and frankly it doesn’t work very well at present. We’re working our best to improve this process. + **Note:** `new_plugin` kicks off a completely separate process, and frankly it doesn't work very well at present. We're working our best to improve this process. diff --git a/docs/docsite/rst/community/reporting_bugs_and_features.rst b/docs/docsite/rst/community/reporting_bugs_and_features.rst index c054a551637..c9ee43172ee 100644 --- a/docs/docsite/rst/community/reporting_bugs_and_features.rst +++ b/docs/docsite/rst/community/reporting_bugs_and_features.rst @@ -25,7 +25,7 @@ For multiple-file content, we encourage use of gist.github.com. Online pastebin If you are not sure if something is a bug yet, you are welcome to ask about something on the mailing list or IRC first. -As we are a very high volume project, if you determine that you do have a bug, please be sure to open the issue yourself to ensure we have a record of it. Don’t rely on someone else in the community to file the bug report for you. +As we are a very high volume project, if you determine that you do have a bug, please be sure to open the issue yourself to ensure we have a record of it. Don't rely on someone else in the community to file the bug report for you. Requesting a feature ==================== diff --git a/docs/docsite/rst/dev_guide/developing_modules_checklist.rst b/docs/docsite/rst/dev_guide/developing_modules_checklist.rst index c936b07dab5..da12a9623c3 100644 --- a/docs/docsite/rst/dev_guide/developing_modules_checklist.rst +++ b/docs/docsite/rst/dev_guide/developing_modules_checklist.rst @@ -55,7 +55,7 @@ The complete module metadata specification is here: `Ansible metadata block `_. :status: This field records information about the module that is - important to the end user. It’s a list of strings. The default value - is a single element list [“preview”]. The following strings are valid + important to the end user. It's a list of strings. The default value + is a single element list ["preview"]. The following strings are valid statuses and have the following meanings: - :stableinterface: This means that the module’s parameters are + :stableinterface: This means that the module's parameters are stable. Every effort will be made not to remove parameters or change - their meaning. It is not a rating of the module’s code quality. + their meaning. It is not a rating of the module's code quality. :preview: This module is a tech preview. This means it may be unstable, the parameters may change, or it may require libraries or web services that are themselves subject to incompatible changes. diff --git a/docs/docsite/rst/dev_guide/overview_architecture.rst b/docs/docsite/rst/dev_guide/overview_architecture.rst index f315d55540d..0eaaf5f9251 100644 --- a/docs/docsite/rst/dev_guide/overview_architecture.rst +++ b/docs/docsite/rst/dev_guide/overview_architecture.rst @@ -25,7 +25,7 @@ Inventory By default, Ansible represents what machines it manages using a very simple INI file that puts all of your managed machines in groups of your own choosing. -To add new machines, there is no additional SSL signing server involved, so there's never any hassle deciding why a particular machine didn’t get linked up due to obscure NTP or DNS issues. +To add new machines, there is no additional SSL signing server involved, so there's never any hassle deciding why a particular machine didn't get linked up due to obscure NTP or DNS issues. If there's another source of truth in your infrastructure, Ansible can also plugin to that, such as drawing inventory, group, and variable information from sources like EC2, Rackspace, OpenStack, and more. @@ -69,4 +69,4 @@ Here's what a simple playbook looks like:: Extending Ansible with Plug-ins and the API ```````````````````````````````````````````` -Should you want to write your own, Ansible modules can be written in any language that can return JSON (Ruby, Python, bash, etc). Inventory can also plug in to any datasource by writing a program that speaks to that datasource and returns JSON. There's also various Python APIs for extending Ansible’s connection types (SSH is not the only transport possible), callbacks (how Ansible logs, etc), and even for adding new server side behaviors. +Should you want to write your own, Ansible modules can be written in any language that can return JSON (Ruby, Python, bash, etc). Inventory can also plug in to any datasource by writing a program that speaks to that datasource and returns JSON. There's also various Python APIs for extending Ansible's connection types (SSH is not the only transport possible), callbacks (how Ansible logs, etc), and even for adding new server side behaviors. diff --git a/docs/docsite/rst/dev_guide/style_guide/grammar_punctuation.rst b/docs/docsite/rst/dev_guide/style_guide/grammar_punctuation.rst index 7a07bd4f5e2..d15853ae887 100644 --- a/docs/docsite/rst/dev_guide/style_guide/grammar_punctuation.rst +++ b/docs/docsite/rst/dev_guide/style_guide/grammar_punctuation.rst @@ -110,7 +110,7 @@ Never use "we" when writing. "We" aren't doing anything on the user side. Ansibl Hyphen ~~~~~~~~~~~~~~ -The hyphen’s primary function is the formation of certain compound terms. Do not use a hyphen unless it serves a purpose. If a compound adjective cannot be misread or, as with many psychological terms, its meaning is established, a hyphen is not necessary. +The hyphen's primary function is the formation of certain compound terms. Do not use a hyphen unless it serves a purpose. If a compound adjective cannot be misread or, as with many psychological terms, its meaning is established, a hyphen is not necessary. Use hyphens to avoid ambiguity or confusion: diff --git a/docs/docsite/rst/dev_guide/style_guide/spelling_word_choice.rst b/docs/docsite/rst/dev_guide/style_guide/spelling_word_choice.rst index 2e18c51381a..bc5f43a5316 100644 --- a/docs/docsite/rst/dev_guide/style_guide/spelling_word_choice.rst +++ b/docs/docsite/rst/dev_guide/style_guide/spelling_word_choice.rst @@ -78,7 +78,7 @@ Use to describes where to place options for a command, but not where to type the Daylight saving time (DST) +++++++++++++++++++++++++++++++ -Correct. Do not use daylight savings time. Daylight Saving Time (DST) is often misspelled “Daylight Savings”, with an “s” at the end. Other common variations are “Summer Time”and “Daylight-Saving Time”. (http://www.timeanddate.com/time/dst/daylight-savings-time.html) +Correct. Do not use daylight savings time. Daylight Saving Time (DST) is often misspelled "Daylight Savings", with an "s" at the end. Other common variations are "Summer Time"and "Daylight-Saving Time". (http://www.timeanddate.com/time/dst/daylight-savings-time.html) Download @@ -99,7 +99,7 @@ When used as a verb, fail over is two words since there can be different tenses Fewer +++++++++++++++++++ -Fewer is used with plural nouns. Think things you could count. Time, money, distance, and weight are often listed as exceptions to the traditional “can you count it” rule, often thought of a singular amounts (the work will take less than 5 hours, for example). +Fewer is used with plural nouns. Think things you could count. Time, money, distance, and weight are often listed as exceptions to the traditional "can you count it" rule, often thought of a singular amounts (the work will take less than 5 hours, for example). File name +++++++++++++ diff --git a/docs/docsite/rst/dev_guide/style_guide/why_use.rst b/docs/docsite/rst/dev_guide/style_guide/why_use.rst index ea478d99d0c..3740eb17e0a 100644 --- a/docs/docsite/rst/dev_guide/style_guide/why_use.rst +++ b/docs/docsite/rst/dev_guide/style_guide/why_use.rst @@ -13,8 +13,8 @@ This style guide incorporates current Ansible resources and information so that
- “If you don't find it in the index, look very carefully through the entire catalogue.” - ― Sears, Roebuck and Co., 1897 Sears Roebuck & Co. Catalogue + "If you don't find it in the index, look very carefully through the entire catalogue." + ― Sears, Roebuck and Co., 1897 Sears Roebuck & Co. Catalogue .. raw:: html diff --git a/docs/docsite/rst/dev_guide/testing/sanity/no-smart-quotes.rst b/docs/docsite/rst/dev_guide/testing/sanity/no-smart-quotes.rst new file mode 100644 index 00000000000..5432b2c63e6 --- /dev/null +++ b/docs/docsite/rst/dev_guide/testing/sanity/no-smart-quotes.rst @@ -0,0 +1,4 @@ +Sanity Tests » no-smart-quotes +============================== + +Smart quotes (``”“‘’``) should not be used. Use plain ascii quotes (``"'``) instead. diff --git a/docs/docsite/rst/guide_azure.rst b/docs/docsite/rst/guide_azure.rst index f0b7831cb5e..d5a6bc4350f 100644 --- a/docs/docsite/rst/guide_azure.rst +++ b/docs/docsite/rst/guide_azure.rst @@ -40,11 +40,11 @@ There is now a detailed official tutorial describing `how to create a service pr After stepping through the tutorial you will have: -* Your Client ID, which is found in the “client id” box in the “Configure” page of your application in the Azure portal +* Your Client ID, which is found in the "client id" box in the "Configure" page of your application in the Azure portal * Your Secret key, generated when you created the application. You cannot show the key after creation. - If you lost the key, you must create a new one in the “Configure” page of your application. -* And finally, a tenant ID. It’s a UUID (e.g. ABCDEFGH-1234-ABCD-1234-ABCDEFGHIJKL) pointing to the AD containing your - application. You will find it in the URL from within the Azure portal, or in the “view endpoints” of any given URL. + If you lost the key, you must create a new one in the "Configure" page of your application. +* And finally, a tenant ID. It's a UUID (e.g. ABCDEFGH-1234-ABCD-1234-ABCDEFGHIJKL) pointing to the AD containing your + application. You will find it in the URL from within the Azure portal, or in the "view endpoints" of any given URL. Using Active Directory Username/Password diff --git a/docs/docsite/rst/intro_bsd.rst b/docs/docsite/rst/intro_bsd.rst index 1fdd9d2ec71..fda19036acd 100644 --- a/docs/docsite/rst/intro_bsd.rst +++ b/docs/docsite/rst/intro_bsd.rst @@ -27,7 +27,7 @@ Bootstrapping BSD As mentioned above, you can bootstrap Ansible with the ``raw`` module and remotely install Python on targets. The following example installs Python 2.7 which includes the json library required for full functionality of Ansible. On your control machine you can simply execute the following for most versions of FreeBSD:: - ansible -m raw -a “pkg install -y python27” mybsdhost1 + ansible -m raw -a "pkg install -y python27" mybsdhost1 Once this is done you can now use other Ansible modules apart from the ``raw`` module. diff --git a/docs/docsite/rst/intro_installation.rst b/docs/docsite/rst/intro_installation.rst index 84c52ca5295..b11f5c682ac 100644 --- a/docs/docsite/rst/intro_installation.rst +++ b/docs/docsite/rst/intro_installation.rst @@ -104,10 +104,10 @@ Installing the Control Machine Latest Release Via Yum ++++++++++++++++++++++ -.. note:: We’ve changed how the Ansible community packages are distributed. +.. note:: We've changed how the Ansible community packages are distributed. For users of RHEL/CentOS/Scientific Linux version 7, the Ansible community RPM package will transition from the EPEL repository to the Extras channel. There will be no - change for version 6 of RHEL/CentOS/Scientific Linux since Extras is not a part of version 6. + change for version 6 of RHEL/CentOS/Scientific Linux since Extras is not a part of version 6. RPMs for RHEL7 are available from `the Extras channel `_. @@ -120,11 +120,11 @@ Ansible will also have RPMs/YUM-repo available at ``_ Questions? Help? Ideas? Stop by the list on Google Groups `irc.freenode.net `_ diff --git a/docs/docsite/rst/modules_support.rst b/docs/docsite/rst/modules_support.rst index 6e48beb410b..7268876a5fe 100644 --- a/docs/docsite/rst/modules_support.rst +++ b/docs/docsite/rst/modules_support.rst @@ -32,9 +32,9 @@ Issue Reporting If you believe you have found a bug in a module and are already running the latest stable or development version of Ansible, first look at the `issue tracker in the Ansible repo `_ to see if an issue has already been filed. If not, please file one. -Should you have a question rather than a bug report, inquiries are welcome on the `ansible-project Google group `_ or on Ansible’s “#ansible” channel, located on irc.freenode.net. +Should you have a question rather than a bug report, inquiries are welcome on the `ansible-project Google group `_ or on Ansible's "#ansible" channel, located on irc.freenode.net. -For development-oriented topics, use the `ansible-devel Google group `_ or Ansible’s #ansible and #ansible-devel channels, located on irc.freenode.net. You should also read :doc:`Community Information & Contributing `, :doc:`Testing Ansible `, and :doc:`Developing Modules `. +For development-oriented topics, use the `ansible-devel Google group `_ or Ansible's #ansible and #ansible-devel channels, located on irc.freenode.net. You should also read :doc:`Community Information & Contributing `, :doc:`Testing Ansible `, and :doc:`Developing Modules `. The modules are hosted on GitHub in a subdirectory of the `Ansible `_ repo. diff --git a/docs/docsite/rst/playbooks_prompts.rst b/docs/docsite/rst/playbooks_prompts.rst index eaf6013ccf1..6b5b2ea0fb1 100644 --- a/docs/docsite/rst/playbooks_prompts.rst +++ b/docs/docsite/rst/playbooks_prompts.rst @@ -77,13 +77,13 @@ You can use any crypt scheme supported by 'Passlib': - *sun_md5_crypt* - Sun MD5 Crypt - *sha256_crypt* - SHA-256 Crypt - *sha512_crypt* - SHA-512 Crypt -- *apr_md5_crypt* - Apache’s MD5-Crypt variant -- *phpass* - PHPass’ Portable Hash +- *apr_md5_crypt* - Apache's MD5-Crypt variant +- *phpass* - PHPass' Portable Hash - *pbkdf2_digest* - Generic PBKDF2 Hashes -- *cta_pbkdf2_sha1* - Cryptacular’s PBKDF2 hash -- *dlitz_pbkdf2_sha1* - Dwayne Litzenberger’s PBKDF2 hash +- *cta_pbkdf2_sha1* - Cryptacular's PBKDF2 hash +- *dlitz_pbkdf2_sha1* - Dwayne Litzenberger's PBKDF2 hash - *scram* - SCRAM Hash -- *bsd_nthash* - FreeBSD’s MCF-compatible nthash encoding +- *bsd_nthash* - FreeBSD's MCF-compatible nthash encoding However, the only parameters accepted are 'salt' or 'salt_size'. You can use your own salt using 'salt', or have one generated automatically using 'salt_size'. If nothing is specified, a salt diff --git a/docs/docsite/rst/porting_guide_2.0.rst b/docs/docsite/rst/porting_guide_2.0.rst index c8774663b7d..56b8851d03c 100644 --- a/docs/docsite/rst/porting_guide_2.0.rst +++ b/docs/docsite/rst/porting_guide_2.0.rst @@ -109,7 +109,7 @@ While all items listed here will show a deprecation warning message, they still * Bare variables in ``with_`` loops should instead use the ``"{ {var }}"`` syntax, which helps eliminate ambiguity. * The ansible-galaxy text format requirements file. Users should use the YAML format for requirements instead. -* Undefined variables within a ``with_`` loop’s list currently do not interrupt the loop, but they do issue a warning; in the future, they will issue an error. +* Undefined variables within a ``with_`` loop's list currently do not interrupt the loop, but they do issue a warning; in the future, they will issue an error. * Using dictionary variables to set all task parameters is unsafe and will be removed in a future version. For example:: - hosts: localhost @@ -129,8 +129,8 @@ While all items listed here will show a deprecation warning message, they still * Host patterns should use a comma (,) or colon (:) instead of a semicolon (;) to separate hosts/groups in the pattern. * Ranges specified in host patterns should use the [x:y] syntax, instead of [x-y]. -* Playbooks using privilege escalation should always use “become*” options rather than the old su*/sudo* options. -* The “short form” for vars_prompt is no longer supported. +* Playbooks using privilege escalation should always use "become*" options rather than the old su*/sudo* options. +* The "short form" for vars_prompt is no longer supported. For example:: vars_prompt: @@ -148,7 +148,7 @@ Should now be:: a: 1 * Setting any_errors_fatal on a task is no longer supported. This should be set at the play level only. -* Bare variables in the `environment` dictionary (for plays/tasks/etc.) are no longer supported. Variables specified there should use the full variable syntax: ‘{{foo}}’. +* Bare variables in the `environment` dictionary (for plays/tasks/etc.) are no longer supported. Variables specified there should use the full variable syntax: '{{foo}}'. * Tags (or any directive) should no longer be specified with other parameters in a task include. Instead, they should be specified as an option on the task. For example:: @@ -159,7 +159,7 @@ Should now be:: - include_tasks: foo.yml tags: [a, b, c] -* The first_available_file option on tasks has been deprecated. Users should use the with_first_found option or lookup (‘first_found’, …) plugin. +* The first_available_file option on tasks has been deprecated. Users should use the with_first_found option or lookup ('first_found', …) plugin. Other caveats diff --git a/docs/docsite/rst/roadmap/ROADMAP_2_1.rst b/docs/docsite/rst/roadmap/ROADMAP_2_1.rst index 7947cd29fac..5f33b77bee9 100644 --- a/docs/docsite/rst/roadmap/ROADMAP_2_1.rst +++ b/docs/docsite/rst/roadmap/ROADMAP_2_1.rst @@ -95,11 +95,11 @@ Expand module diff support (already in progress in devel) Other ----- -Things being kicking down the road that we said we’d do +Things being kicking down the road that we said we'd do - NOT remerging core with ansible/ansible this release cycle Community --------- -- Define the process/ETA for reviewing PR’s from community +- Define the process/ETA for reviewing PR's from community - Publish better docs and how-tos for submitting code/features/fixes diff --git a/docs/docsite/rst/roadmap/ROADMAP_2_2.rst b/docs/docsite/rst/roadmap/ROADMAP_2_2.rst index 78a759a5399..6a2f9435d84 100644 --- a/docs/docsite/rst/roadmap/ROADMAP_2_2.rst +++ b/docs/docsite/rst/roadmap/ROADMAP_2_2.rst @@ -19,7 +19,7 @@ Extras split from Core ---------------------- Lead by Jason M and Jimi-c (Targeting 2.2, could move into 2.3). -Targeted towards the 2.2 release or shortly after, we are planning on splitting Extras out of the “Ansible Core” project.  That means that modules that are shipped with Ansible by default are **only** the modules in ansibl-modules-core.  Ansible extras will become a separate project, managed by the community standard.  Over the next few months we’re going to have a lot of work to do on getting all of the modules in the right places for this to work. +Targeted towards the 2.2 release or shortly after, we are planning on splitting Extras out of the "Ansible Core" project.  That means that modules that are shipped with Ansible by default are **only** the modules in ansibl-modules-core.  Ansible extras will become a separate project, managed by the community standard.  Over the next few months we're going to have a lot of work to do on getting all of the modules in the right places for this to work. - Create proposal (Jason or Jimi) - Review modules for correct location (extras v core) @@ -40,7 +40,7 @@ AWS --- Lead by Ryan Brown -- Pagination for all AWS modules (generic pagination exists, but isn’t used everywhere) (bumped to 2.3) +- Pagination for all AWS modules (generic pagination exists, but isn't used everywhere) (bumped to 2.3) - Refactoring ec2.py to be more digestible (bumped to 2.3) - Fix inconsistencies with different authentication methods (STS, environment creds, ~/.aws/credentials) (done) - AWS Lambda modules (lambda_execute done, others pending) @@ -85,7 +85,7 @@ Lead by Matt D - Feature parity - - PS module API (mirror Python module API where appropriate). Note: We don’t necessarily like the current python module API (AnsibleModule is a huge class with many unrelated utility functions.  Maybe we should redesign both at the same time?) (bumped to 2.3+ due to "moving target" uncertainty) + - PS module API (mirror Python module API where appropriate). Note: We don't necessarily like the current python module API (AnsibleModule is a huge class with many unrelated utility functions.  Maybe we should redesign both at the same time?) (bumped to 2.3+ due to "moving target" uncertainty) - Environment keyword support (done) - win_shell/win_command (done) - Async support (done) @@ -117,7 +117,7 @@ Lead by Nate C, Peter S Role revamp ----------- -- Implement ‘role revamp’ proposal to give users more control on role/task execution (Brian) +- Implement 'role revamp' proposal to give users more control on role/task execution (Brian) - **https://github.com/ansible/proposals/blob/master/roles_revamp.md** @@ -125,13 +125,13 @@ Vault ----- Lead by Jtanner, Adrian -- *Extend ‘transparent vault file usage’ to other action plugins other than 'copy'(https://github.com/ansible/ansible/issues/7298)* +- *Extend 'transparent vault file usage' to other action plugins other than 'copy'(https://github.com/ansible/ansible/issues/7298)* **done:** https://github.com/ansible/ansible/pull/16957 -- Add ‘per variable’ vault support (!vault YAML directive, existing PR already) https://github.com/ansible/ansible/issues/13287 https://github.com/ansible/ansible/issues/14721 +- Add 'per variable' vault support (!vault YAML directive, existing PR already) https://github.com/ansible/ansible/issues/13287 https://github.com/ansible/ansible/issues/14721 - Add vault/unvault filters https://github.com/ansible/ansible/issues/12087 (deferred to 2.3) - Add vault support to lookups (likely deferred to 2.3 or until lookup plugins are revamped) - Allow for multiple vault secrets https://github.com/ansible/ansible/issues/13243 -- Config option to turn ‘unvaulting’ failures into warnings https://github.com/ansible/ansible/issues/13244 +- Config option to turn 'unvaulting' failures into warnings https://github.com/ansible/ansible/issues/13244 Python3 ------- @@ -139,7 +139,7 @@ Lead by Toshio A note here from Jason M: Getting to complete, tested Python 3 is both a critical task and one that has so much work and so many moving parts -that we don’t expect this to be complete by the 2.2 release.  Toshio will +that we don't expect this to be complete by the 2.2 release.  Toshio will lead this overall effort. - Motivation: @@ -173,7 +173,7 @@ lead this overall effort. - Update: copy of the six library (v1.4.1 for python2.4 compat) and unicode helpers are here (ansible.module_utils._text.{to_bytes,to_text,to_native}) - A few basic modules ported to python3 - - Stat module best example module since it’s essential. + - Stat module best example module since it's essential. - Update: - A handful of modules like stat have been line-by-line ported. They should work reliably with few python3-specific bugs. All but three integration tests pass which means that most essential modules are working to some extent on Python3. @@ -186,7 +186,7 @@ lead this overall effort. - lib/ansible/* and all modules now compile under Python-3.5 - Side work to do: - - Figure out best ways to run unit-tests on modules.  Start unit-testing modules.  This is going to become important so we don’t regress python3 or python2.4 support in modules  (Going to largely punt on this for 2.2.  Matt Clay is working on building us a testing foundation for the first half of 2.2 development so we’ll re-evaluate towards the middle of the dev cycle). + - Figure out best ways to run unit-tests on modules.  Start unit-testing modules.  This is going to become important so we don't regress python3 or python2.4 support in modules  (Going to largely punt on this for 2.2.  Matt Clay is working on building us a testing foundation for the first half of 2.2 development so we'll re-evaluate towards the middle of the dev cycle). - More unit tests of module_utils - More integration tests. Currently integration tests are the best way to test ansible modules so we have to rely on those. @@ -202,7 +202,7 @@ Infrastructure Buildout and Changes ----------------------------------- Lead by Matt Clay -Another note from Jason M: A lot of this work is to ease the burden of CI, CI performance, increase our testing coverage and all of that sort of thing.  It’s not necessarily feature work, but it’s \*\*critical\*\* to growing our product and our ability to get community changes in more securely and quickly. +Another note from Jason M: A lot of this work is to ease the burden of CI, CI performance, increase our testing coverage and all of that sort of thing.  It's not necessarily feature work, but it's \*\*critical\*\* to growing our product and our ability to get community changes in more securely and quickly. - **CI Performance** Reduce time spent waiting on CI for PRs. Combination of optimizing existing Travis setup and offloading work to other services. Will be impacted by available budget. diff --git a/docs/docsite/rst/roadmap/ROADMAP_2_3.rst b/docs/docsite/rst/roadmap/ROADMAP_2_3.rst index c899f3f7da1..39a0e6fdd47 100644 --- a/docs/docsite/rst/roadmap/ROADMAP_2_3.rst +++ b/docs/docsite/rst/roadmap/ROADMAP_2_3.rst @@ -46,7 +46,7 @@ Lead by nitzmahone - Become support **(done/experimental)** - Integrated kerberos ticket management (via ansible_user/ansible_password) **(done)** - Switch PS input encoding to BOM-less UTF8 **(done)** - - Server 2016 support/testing (now RTM’d) **(partial)** + - Server 2016 support/testing (now RTM'd) **(partial)** - Modularize Windows module_utils (allow N files) **(partial)** - Declarative argspec for PS / .NET **(bumped to 2.4)** - Kerberos encryption (via notting, pywinrm/requests_kerberos/pykerberos) **(in progress, available in pywinrm post 2.3 release)** @@ -98,8 +98,8 @@ Python3 - If users report bugs on python3, these should be fixed and will prioritize our work on porting other modules. -- Still have to solve the python3-only and python2-only modules. Thinking of doing this via metadata. Will mean we have to use metadata at the module_common level. Will also mean we don’t support py2-only or py3-only old style python modules. -- Note: Most of the currently tested ansible features now run. But there’s still a lot of code that’s untested. +- Still have to solve the python3-only and python2-only modules. Thinking of doing this via metadata. Will mean we have to use metadata at the module_common level. Will also mean we don't support py2-only or py3-only old style python modules. +- Note: Most of the currently tested ansible features now run. But there's still a lot of code that's untested. Testing and CI -------------- @@ -157,7 +157,7 @@ Plugin Loader ansible-ssh ----------- -- Add a ‘ansible-ssh’ convenience and debugging tool (will slip to 2.4) +- Add a 'ansible-ssh' convenience and debugging tool (will slip to 2.4) - Tool to invoke an interactive ssh to a host with the same args/env/config that ansible would. - There are at least three external versions diff --git a/docs/docsite/rst/roadmap/ROADMAP_2_4.rst b/docs/docsite/rst/roadmap/ROADMAP_2_4.rst index b8b6cf3d1d2..863550b1136 100644 --- a/docs/docsite/rst/roadmap/ROADMAP_2_4.rst +++ b/docs/docsite/rst/roadmap/ROADMAP_2_4.rst @@ -56,7 +56,7 @@ Inventory Facts ----- -- Configurable list of ‘fact modules’ for ``gather_facts`` **(done)** +- Configurable list of 'fact modules' for ``gather_facts`` **(done)** - Fact gathering policy finer grained **(done)** - Make ``setup.py``/``facts`` more pluggable **(done)** - Improve testing of ``setup.py``/``facts.py`` **(done)** @@ -104,8 +104,8 @@ Globalize Callbacks ------------------- **(pushed out to future release)** - Make send_callback available to other code that cannot use it. -- Would allow for ‘full formatting’ of output (see JSON callback) -- Fixes static ‘include’ display problem +- Would allow for 'full formatting' of output (see JSON callback) +- Fixes static 'include' display problem Plugins ------- @@ -128,13 +128,13 @@ Runtime Check on Modules for Blacklisting Disambiguate Includes --------------------- -- Create import_x for ‘static includes’ (import_task, import_play, import_role) +- Create import_x for 'static includes' (import_task, import_play, import_role) - - Any directives are applied to the ‘imported’ tasks + - Any directives are applied to the 'imported' tasks -- Create include_x for ‘dynamic includes’ (include_task, include_role) +- Create include_x for 'dynamic includes' (include_task, include_role) - - Any directives apply to the ‘include’ itself + - Any directives apply to the 'include' itself Windows ------- diff --git a/docs/docsite/rst_common/ansible_ssh_changes_note.rst b/docs/docsite/rst_common/ansible_ssh_changes_note.rst index ccc289d89db..c9364c90daa 100644 --- a/docs/docsite/rst_common/ansible_ssh_changes_note.rst +++ b/docs/docsite/rst_common/ansible_ssh_changes_note.rst @@ -1,3 +1,3 @@ .. note:: - Ansible 2.0 has deprecated the “ssh” from ``ansible_ssh_user``, ``ansible_ssh_host``, and ``ansible_ssh_port`` to become ``ansible_user``, ``ansible_host``, and ``ansible_port``. If you are using a version of Ansible prior to 2.0, you should continue using the older style variables (``ansible_ssh_*``). These shorter variables are ignored, without warning, in older versions of Ansible. + Ansible 2.0 has deprecated the "ssh" from ``ansible_ssh_user``, ``ansible_ssh_host``, and ``ansible_ssh_port`` to become ``ansible_user``, ``ansible_host``, and ``ansible_port``. If you are using a version of Ansible prior to 2.0, you should continue using the older style variables (``ansible_ssh_*``). These shorter variables are ignored, without warning, in older versions of Ansible. diff --git a/lib/ansible/modules/cloud/dimensiondata/dimensiondata_network.py b/lib/ansible/modules/cloud/dimensiondata/dimensiondata_network.py index caa36bb7ada..75ae740340e 100644 --- a/lib/ansible/modules/cloud/dimensiondata/dimensiondata_network.py +++ b/lib/ansible/modules/cloud/dimensiondata/dimensiondata_network.py @@ -40,7 +40,7 @@ options: required: false service_plan: description: - - The service plan, either “ESSENTIALS” or “ADVANCED”. + - The service plan, either "ESSENTIALS" or "ADVANCED". - MCP 2.0 Only. choices: [ESSENTIALS, ADVANCED] default: ESSENTIALS diff --git a/lib/ansible/modules/cloud/misc/proxmox_kvm.py b/lib/ansible/modules/cloud/misc/proxmox_kvm.py index cc6fcea909f..53c125d7e45 100644 --- a/lib/ansible/modules/cloud/misc/proxmox_kvm.py +++ b/lib/ansible/modules/cloud/misc/proxmox_kvm.py @@ -136,7 +136,7 @@ options: required: false format: description: - - Target drive’s backing file’s data format. + - Target drive's backing file's data format. - Used only with clone default: qcow2 choices: [ "cloop", "cow", "qcow", "qcow2", "qed", "raw", "vmdk" ] @@ -162,7 +162,7 @@ options: - Values allowed are - C("host="HOSTPCIID[;HOSTPCIID2...]",pcie="1|0",rombar="1|0",x-vga="1|0""). - The C(host) parameter is Host PCI device pass through. HOSTPCIID syntax is C(bus:dev.func) (hexadecimal numbers). - C(pcie=boolean) I(default=0) Choose the PCI-express bus (needs the q35 machine model). - - C(rombar=boolean) I(default=1) Specify whether or not the device’s ROM will be visible in the guest’s memory map. + - C(rombar=boolean) I(default=1) Specify whether or not the device's ROM will be visible in the guest's memory map. - C(x-vga=boolean) I(default=0) Enable vfio-vga device support. - /!\ This option allows direct access to host hardware. So it is no longer possible to migrate such machines - use with special care. required: false @@ -187,7 +187,7 @@ options: - Values allowed are - C("storage:size,format=value"). - C(storage) is the storage identifier where to create the disk. - C(size) is the size of the disk in GB. - - C(format) is the drive’s backing file’s data format. C(qcow2|raw|subvol). + - C(format) is the drive's backing file's data format. C(qcow2|raw|subvol). required: false default: null keyboard: @@ -327,7 +327,7 @@ options: - Values allowed are - C("storage:size,format=value"). - C(storage) is the storage identifier where to create the disk. - C(size) is the size of the disk in GB. - - C(format) is the drive’s backing file’s data format. C(qcow2|raw|subvol). + - C(format) is the drive's backing file's data format. C(qcow2|raw|subvol). default: null required: false scsi: @@ -337,7 +337,7 @@ options: - Values allowed are - C("storage:size,format=value"). - C(storage) is the storage identifier where to create the disk. - C(size) is the size of the disk in GB. - - C(format) is the drive’s backing file’s data format. C(qcow2|raw|subvol). + - C(format) is the drive's backing file's data format. C(qcow2|raw|subvol). default: null required: false scsihw: @@ -469,7 +469,7 @@ options: - Values allowed are - C("storage:size,format=value"). - C(storage) is the storage identifier where to create the disk. - C(size) is the size of the disk in GB. - - C(format) is the drive’s backing file’s data format. C(qcow2|raw|subvol). + - C(format) is the drive's backing file's data format. C(qcow2|raw|subvol). required: false default: null vmid: diff --git a/lib/ansible/modules/clustering/consul_session.py b/lib/ansible/modules/clustering/consul_session.py index 9e4dba5c109..e3797b99485 100644 --- a/lib/ansible/modules/clustering/consul_session.py +++ b/lib/ansible/modules/clustering/consul_session.py @@ -98,7 +98,7 @@ options: behavior: description: - the optional behavior that can be attached to the session when it - is created. This can be set to either ‘release’ or ‘delete’. This + is created. This can be set to either 'release' or 'delete'. This controls the behavior when a session is invalidated. default: release required: false diff --git a/lib/ansible/modules/monitoring/circonus_annotation.py b/lib/ansible/modules/monitoring/circonus_annotation.py index 631d8897129..095ab7aee94 100644 --- a/lib/ansible/modules/monitoring/circonus_annotation.py +++ b/lib/ansible/modules/monitoring/circonus_annotation.py @@ -24,7 +24,7 @@ version_added: 2.0 requirements: - requests (either >= 2.0.0 for Python 3, or >= 1.0.0 for Python 2) notes: - - Check mode isn’t supported. + - Check mode isn't supported. options: api_key: description: diff --git a/lib/ansible/modules/network/lenovo/cnos_conditional_command.py b/lib/ansible/modules/network/lenovo/cnos_conditional_command.py index 1f4c9ba7528..6258062570d 100644 --- a/lib/ansible/modules/network/lenovo/cnos_conditional_command.py +++ b/lib/ansible/modules/network/lenovo/cnos_conditional_command.py @@ -39,7 +39,7 @@ description: The CNOS command is passed as an argument of the method. This module functions the same as the cnos_command module. The only exception is that the following inventory variable can be specified - [“condition = ”] + ["condition = "] When this inventory variable is specified as the variable of a task, the command is executed for the network element that matches the flag string. Usually, commands are executed across a group of network devices. When there is a requirement to skip the execution of the command on one or diff --git a/lib/ansible/modules/network/lenovo/cnos_conditional_template.py b/lib/ansible/modules/network/lenovo/cnos_conditional_template.py index b6e0c7ed03e..7de872944c7 100644 --- a/lib/ansible/modules/network/lenovo/cnos_conditional_template.py +++ b/lib/ansible/modules/network/lenovo/cnos_conditional_template.py @@ -39,7 +39,7 @@ description: The configuration source can be a set of commands or a template written in the Jinja2 templating language. This module functions the same as the cnos_template module. The only exception is that the following inventory variable can be specified - [“condition = ”] + ["condition = "] When this inventory variable is specified as the variable of a task, the template is executed for the network element that matches the flag string. Usually, templates are used when commands are the same across a group of network devices. When there is a requirement to skip the execution of the diff --git a/lib/ansible/modules/network/lenovo/cnos_factory.py b/lib/ansible/modules/network/lenovo/cnos_factory.py index 70dcd095176..5e3ba817e3d 100644 --- a/lib/ansible/modules/network/lenovo/cnos_factory.py +++ b/lib/ansible/modules/network/lenovo/cnos_factory.py @@ -33,7 +33,7 @@ module: cnos_factory author: "Dave Kasberg (@dkasberg)" short_description: Reset the switch's startup configuration to default (factory) on devices running Lenovo CNOS description: - - This module allows you to reset a switch’s startup configuration. The method provides a way to reset the + - This module allows you to reset a switch's startup configuration. The method provides a way to reset the startup configuration to its factory settings. This is helpful when you want to move the switch to another topology as a new network device. This module uses SSH to manage network device configuration. diff --git a/lib/ansible/modules/network/lenovo/cnos_image.py b/lib/ansible/modules/network/lenovo/cnos_image.py index 28f1371f446..52dc5038d8e 100644 --- a/lib/ansible/modules/network/lenovo/cnos_image.py +++ b/lib/ansible/modules/network/lenovo/cnos_image.py @@ -35,7 +35,7 @@ short_description: Perform firmware upgrade/download from a remote server on dev description: - This module allows you to work with switch firmware images. It provides a way to download a firmware image to a network device from a remote server using FTP, SFTP, TFTP, or SCP. The first step is to create a directory - from where the remote server can be reached. The next step is to provide the full file path of the image’s + from where the remote server can be reached. The next step is to provide the full file path of the image's location. Authentication details required by the remote server must be provided as well. By default, this method makes the newly downloaded firmware image the active image, which will be used by the switch during the next restart. diff --git a/lib/ansible/modules/network/lenovo/cnos_rollback.py b/lib/ansible/modules/network/lenovo/cnos_rollback.py index 08754cd77c4..94e82467939 100644 --- a/lib/ansible/modules/network/lenovo/cnos_rollback.py +++ b/lib/ansible/modules/network/lenovo/cnos_rollback.py @@ -38,9 +38,9 @@ description: of a switch from a remote server. This is achieved by using startup or running configurations of the target device that were previously backed up to a remote server using FTP, SFTP, TFTP, or SCP. The first step is to create a directory from where the remote server can be reached. The next step is to - provide the full file path of the backup configuration’s location. Authentication details required by the + provide the full file path of the backup configuration's location. Authentication details required by the remote server must be provided as well. - By default, this method overwrites the switch’s configuration file with the newly downloaded file. + By default, this method overwrites the switch's configuration file with the newly downloaded file. This module uses SSH to manage network device configuration. The results of the operation will be placed in a directory named 'results' that must be created by the user in their local directory to where the playbook is run. diff --git a/lib/ansible/modules/web_infrastructure/gunicorn.py b/lib/ansible/modules/web_infrastructure/gunicorn.py index e9c3d17543d..2a2acad619b 100644 --- a/lib/ansible/modules/web_infrastructure/gunicorn.py +++ b/lib/ansible/modules/web_infrastructure/gunicorn.py @@ -50,7 +50,7 @@ options: worker: choices: ['sync', 'eventlet', 'gevent', 'tornado ', 'gthread', 'gaiohttp'] description: - - 'The type of workers to use. The default class (sync) should handle most “normal” types of workloads.' + - 'The type of workers to use. The default class (sync) should handle most "normal" types of workloads.' user: description: - 'Switch worker processes to run as this user.' diff --git a/lib/ansible/modules/web_infrastructure/letsencrypt.py b/lib/ansible/modules/web_infrastructure/letsencrypt.py index 517c8382d4d..1f2a0366593 100644 --- a/lib/ansible/modules/web_infrastructure/letsencrypt.py +++ b/lib/ansible/modules/web_infrastructure/letsencrypt.py @@ -20,9 +20,9 @@ author: "Michael Gruener (@mgruener)" version_added: "2.2" short_description: Create SSL certificates with Let's Encrypt description: - - "Create and renew SSL certificates with Let's Encrypt. Let’s Encrypt is a + - "Create and renew SSL certificates with Let's Encrypt. Let's Encrypt is a free, automated, and open certificate authority (CA), run for the - public’s benefit. For details see U(https://letsencrypt.org). The current + public's benefit. For details see U(https://letsencrypt.org). The current implementation supports the http-01, tls-sni-02 and dns-01 challenges." - "To use this module, it has to be executed at least twice. Either as two different tasks in the same run or during multiple runs." diff --git a/test/integration/roles/cnos_bgp/README.md b/test/integration/roles/cnos_bgp/README.md index 74d3d1a8953..ee28ebabcce 100644 --- a/test/integration/roles/cnos_bgp/README.md +++ b/test/integration/roles/cnos_bgp/README.md @@ -56,7 +56,7 @@ Variable | Description `bgpArg5` | This is an overloaded BGP variable. Please refer to the [cnos_bgp module documentation](http://ralfss28.labs.lenovo.com:5555/help/topic/com.lenovo.switchmgt.ansible.doc/cnos_bgp.html?cp=0_3_1_0_2_13) for detailed information on usage. The values of these variables depend on the configuration context and the choices are the following: **as-set**, **summary-only**, name of the route map that controls where BGP route dampening is enabled, value to start reusing a route, administrative distance to routes inside the AS, value for maximum path numbers, **backdoor**, **mask**, **route-map**. `bgpArg6` | This is an overloaded BGP variable. Please refer to the [cnos_bgp module documentation](http://ralfss28.labs.lenovo.com:5555/help/topic/com.lenovo.switchmgt.ansible.doc/cnos_bgp.html?cp=0_3_1_0_2_13) for detailed information on usage. The values of these variables depend on the configuration context and the choices are the following: **summary-only**, **as-set**, value to start suppressing a route, administrative distance for local routes, IP subnet address mask, name of the route map. `bgpArg7` | This is an overloaded BGP variable. Please refer to the [cnos_bgp module documentation](http://ralfss28.labs.lenovo.com:5555/help/topic/com.lenovo.switchmgt.ansible.doc/cnos_bgp.html?cp=0_3_1_0_2_13) for detailed information on usage. The values of these variables depend on the configuration context and the choices are the following: maximum duration to suppress a stable route, **route-map**, **backdoor**. -`bgpArg8` | This is an overloaded BGP variable. Please refer to the [cnos_bgp module documentation](http://ralfss28.labs.lenovo.com:5555/help/topic/com.lenovo.switchmgt.ansible.doc/cnos_bgp.html?cp=0_3_1_0_2_13) for detailed information on usage. The values of these variables depend on the configuration context and the choices are the following: time after which an unreachable route’s penalty is decreased by half, **backdoor**. +`bgpArg8` | This is an overloaded BGP variable. Please refer to the [cnos_bgp module documentation](http://ralfss28.labs.lenovo.com:5555/help/topic/com.lenovo.switchmgt.ansible.doc/cnos_bgp.html?cp=0_3_1_0_2_13) for detailed information on usage. The values of these variables depend on the configuration context and the choices are the following: time after which an unreachable route's penalty is decreased by half, **backdoor**. ## Dependencies diff --git a/test/integration/roles/cnos_image/README.md b/test/integration/roles/cnos_image/README.md index d9d35c096d4..c839ae20629 100644 --- a/test/integration/roles/cnos_image/README.md +++ b/test/integration/roles/cnos_image/README.md @@ -4,7 +4,7 @@ This role is an example of using the *cnos_image.py* Lenovo module in the context of CNOS switch configuration. This module allows you to work with switch firmware images. It provides a way to download a firmware image to a network device from a remote server using FTP, SFTP, TFTP, or SCP. -The first step is to create a directory from where the remote server can be reached. The next step is to provide the full file path of the image’s location. Authentication details required by the remote server must be provided as well. +The first step is to create a directory from where the remote server can be reached. The next step is to provide the full file path of the image's location. Authentication details required by the remote server must be provided as well. By default, this method makes the newly downloaded firmware image the active image, which will be used by the switch during the next restart. diff --git a/test/integration/roles/cnos_rollback/README.md b/test/integration/roles/cnos_rollback/README.md index bb346004b1d..826ed107eab 100644 --- a/test/integration/roles/cnos_rollback/README.md +++ b/test/integration/roles/cnos_rollback/README.md @@ -4,9 +4,9 @@ This role is an example of using the *cnos_rollback.py* Lenovo module in the context of CNOS switch configuration.This module allows you to work with switch configurations. It provides a way to roll back configurations of a switch from a remote server. This is achieved by using startup or running configurations of the target device that were previously backed up to a remote server using FTP, SFTP, TFTP, or SCP. -The first step is to create a directory from where the remote server can be reached. The next step is to provide the full file path of the backup configuration’s location. Authentication details required by the remote server must be provided as well. +The first step is to create a directory from where the remote server can be reached. The next step is to provide the full file path of the backup configuration's location. Authentication details required by the remote server must be provided as well. -By default, this method overwrites the switch’s configuration file with the newly downloaded file. +By default, this method overwrites the switch's configuration file with the newly downloaded file. The results of the operation can be viewed in *results* directory. diff --git a/test/sanity/code-smell/no-smart-quotes.sh b/test/sanity/code-smell/no-smart-quotes.sh new file mode 100755 index 00000000000..de5f6c43bd8 --- /dev/null +++ b/test/sanity/code-smell/no-smart-quotes.sh @@ -0,0 +1,23 @@ +#!/bin/sh + +# shellcheck disable=SC1015,SC1016 +egrep -r '[‘’“”]' . \ + --exclude-dir .git \ + --exclude-dir .tox \ + | grep -v \ + -e './test/sanity/code-smell/no-smart-quotes.sh' \ + -e './docs/docsite/rst/dev_guide/testing/sanity/no-smart-quotes.rst' \ + -e './test/integration/targets/unicode/unicode.yml' \ + -e '\.doctree matches$' \ + -e '\.pickle matches$' \ + -e './docs/docsite/_build/html/' + +if [ $? -ne 1 ]; then + printf 'The file(s) listed above have non-ascii quotes.\n' + # shellcheck disable=SC1015,SC1016 + printf 'Make sure all files use " and '"'"' as quotation marks\n' + printf 'These sed commands may be of help to you:\n' + # shellcheck disable=SC1015,SC1016 + printf " sed 's/[”“]/\"/g' \$FILENAME -i && sed \"s/[‘’]/'/g\" \$FILENAME -i\\n" + exit 1 +fi