opensourcemirror
/
ansible
mirror of https://github.com/ansible/ansible.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Tidy up Contributors Docs (#47619) 

* Tidy up docs on GitHub, direct people to docs.ansible.com
* De-duplicate documentation and move useful info
This commit is contained in:
John R Barker 2018-10-28 22:11:40 +00:00 committed by Alicia Cozine
parent 166e84b9c4
commit 72359a10e6
7 changed files with 74 additions and 357 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

13
.github/CONTRIBUTING.md vendored
View File

@ -4,25 +4,22 @@ Hi! Nice to see you here!
## QUESTIONS ?
Please see the [community guide](https://docs.ansible.com/ansible/latest/community/index.html) for information on how to ask questions on the [mailing lists](https://docs.ansible.com/ansible/latest/community/communication.html#mailing-list-information) and IRC.
Please see the [Community Guide](https://docs.ansible.com/ansible/latest/community/index.html) for information on how to ask questions on the [mailing lists](https://docs.ansible.com/ansible/latest/community/communication.html#mailing-list-information) and IRC.
The GitHub issue tracker is not the best place for questions for various reasons, but both IRC and the mailing list are very helpful places for those things, as the community page explains best.
## CONTRIBUTING ?
By contributing you agree that these contributions are your own (or approved by your employer) and you grant a full, complete, irrevocable copyright license to all users and developers of the project, present and future, pursuant to the license of the project.
By contributing you agree that these contributions are your own (or approved by your employer) and you grant a full, complete, irrevocable copyright license to all users and developers of the project, present and future, pursuant to the license of the project. You can also read the same [CLA](https://docs.ansible.com/ansible/latest/community/contributor_license_agreement.html) on the Ansible docsite.
Please see the [community guide](https://docs.ansible.com/ansible/latest/community/index.html) for information regarding the contribution process. Important license agreement information is also included on that page.
Please review the [Community Guide](https://docs.ansible.com/ansible/latest/community/index.html) for more information on contributing to Ansible.
## BUG TO REPORT ?
First and foremost, also check the [community guide](https://docs.ansible.com/ansible/latest/community/index.html).
First and foremost, also check the [Community Guide](https://docs.ansible.com/ansible/latest/community/index.html).
You can report bugs or make enhancement requests at the [Ansible GitHub issue page](http://github.com/ansible/ansible/issues/new/choose) by filling out the issue template that will be presented.
Also please make sure you are testing on the latest released version of Ansible or the development branch. You can find the latest releases and development branch at:
- https://github.com/ansible/ansible/releases
- https://github.com/ansible/ansible/archive/devel.tar.gz
Also please make sure you are testing on the latest released version of Ansible or the development branch; see the [Installation Guide](https://docs.ansible.com/ansible/latest/installation_guide/intro_installation.html) for details.
Thanks!

314
CODING_GUIDELINES.md
View File

@ -1,316 +1,10 @@
Coding Guidelines
=================
Hi! Thanks for your interest in contributing to Ansible.
Hi! Thanks for your interest in contributing to Ansible. We document our Coding Guidelines in the [Developer Guide](https://docs.ansible.com/ansible/devel/dev_guide/). We particularly suggest you review:
Here are some guidelines for contributing code. The purpose of this document is to establish what we're looking for in code contributions, and to make sure
new contributors know some of the conventions that we've been using.
* [Contributing your module to Ansible](https://docs.ansible.com/ansible/devel/dev_guide/developing_modules_checklist.html)
We don't think much of this should be too strange to readers familiar with contributing to Python projects, though it helps if we all get on the same page.
* [Development conventions, tips and pitfalls](https://docs.ansible.com/ansible/devel/dev_guide/developing_modules_best_practices.html)
Language
========
* While not all components of Ansible must be in Python, core contributions to the Ansible repo must be written in Python. This is to maximize the ability of everyone to contribute.
* If you want to write non-Python ansible modules or inventory scripts, that's fine, but they are not going to get merged in most likely. Sorry!!
PEP 8 and basic style checks
============================
* [PEP 8](https://www.python.org/dev/peps/pep-0008/) is a great Python style guide, which you should read.
* PEP 8 must not be strictly followed in all aspects, but most of it is good advice.
* The line is limited to 160 characters.
* To run checks for things we care about, use [ansible-test](https://docs.ansible.com/ansible/devel/dev_guide/testing_sanity.html).
* Similarly, additional checks can be made with "make pyflakes".
* There is no need to submit code changes for PEP 8 and pyflakes fixes, as these break attribution history. Project leadership will make these periodically.
* Do not submit pull requests that simply adjust whitespace in the code.
Testing
=======
* Much of Ansible's testing needs are in integration, not unit tests. Add module tests there.
* That being said, there are unit tests too!
* Code written must absolutely pass tests (i.e. "make tests")
* You should anticipate any error paths in your code and test down those error paths.
* Additions to tests for core code are welcome, but not always possible. Be sure things are at least well tested manually in that case.
Whitespace
==========
* Four space indent is strictly required
* Include meaningful whitespace between lines of code
Shebang Lines
=============
* /usr/bin/scripts should start with '/usr/bin/env python'
* module code should still use '/usr/bin/python' as this is replaced automatically by 'ansible_python_interpreter', see the FAQ in the docs for more info.
Comments
========
* Readability is one of the most important goals for this project
* Comment any non-trivial code where someone might not know why you are doing something in a particular way
* Though if something should be commented, that's often a sign someone should write a function
* All new functions must have a basic docstring comment
* Commenting above a line is preferable to commenting at the end of a line
Classes
=======
* With the exception of module code (where inline is better), it is desirable to see classes in their own files.
* Classes should generally not cause side effects as soon as they are instantiated, move meaningful behavior to methods rather than constructors.
Functions and Methods
=====================
* In general, functions should not be 'too long' and should describe a meaningful amount of work
* When code gets too nested, that's usually the sign the loop body could benefit from being a function
* Parts of our existing code are not the best examples of this at times.
* Functions should have names that describe what they do, along with docstrings
* Functions should be named with_underscores
* "Don't repeat yourself" is generally a good philosophy
Variables
=========
* Use descriptive variable names instead of variables like 'x', unless x is an obvious loop index
* Ansible python code uses identifiers like 'ClassesLikeThis and variables_like_this
* Module parameters should also use_underscores and not runtogether
Module Security
===============
* Modules must take steps to avoid passing user input from the shell and always check return codes
* always use module.run_command instead of subprocess or Popen or os.system -- this is mandatory
* if you need to use the shell you must pass use_unsafe_shell=True to module.run_command
* if you do not need the shell, avoid using the shell
* any variables that can come from the user input with use_unsafe_shell=True must be wrapped by pipes.quote(x)
* downloads of https:// resource urls must import module_utils.urls and use the fetch_url method
Misc Preferences
================
Use the dict constructor where possible when allocating dictionaries:
# not this:
foo = {
'a' : 12,
'b' : 34
}
# this:
foo = dict(
a=12,
b=34,
)
Do not line up variables
# not this
a = 12
foosball = 34
xyz = 'dog'
# this
a = 12
foosball = 34
xyz = 'dog'
Don't use line continuations:
# no
if (this_is_a_very_long_line and foo and \
i_am_going_to_continue_it):
bar()
# better:
if (this_is_a_very_long_line and foo and i_am_going_to_continue_it):
bar()
Spacing:
# no
x = [1,2,3]
# no
x = [ 1, 2, 3 ]
# yes
x = [1, 2, 3]
Spacing continued:
# no
x=foo(12)
# no
x = foo( 12 )
# yes
x = foo(12)
Licenses
========
Every file should have a license header, including the copyright of the original author. Major additions to the module are allowed
to add an additional copyright line, and this is especially true of rewrites, but original authorship copyright messages should be preserved.
All contributions to the core repo should preserve original licenses and new contributions must include the GPLv3 header.
Module Documentation
====================
All module pull requests must include a DOCUMENTATION docstring (YAML format,
see other modules for examples) as well as an EXAMPLES docstring, which is free form.
When adding new modules, any new parameter must have a "version_added" attribute.
When submitting a new module, the module should have a "version_added" attribute in the
pull request as well, set to the current development version.
Be sure to check grammar and spelling.
It's frequently the case that modules get submitted with YAML that isn't valid,
so you can run "make webdocs" from the checkout to preview your module's documentation.
If it fails to build, take a look at your DOCUMENTATION string
or you might have a Python syntax error in there too.
Python Imports
==============
To make it clear what a module is importing, imports should not be sprinkled throughout the code.
Python Imports should happen at the top of the file, exempting code from module_utils.
When a conditional runtime import is required, do so something like this instead:
HAS_FOO = False
try:
import foo
HAS_FOO = True
except ImportError:
pass
...
if not HAS_FOO:
raise Exception("the foo library is required")
This makes it clear what optional dependencies are but allows this to be deferred until runtime. In the case of module code, the raising of the Exception will be replaced
with a "module.exit_json" call.
Exceptions
==========
In the main body of the code, use typed exceptions where possible:
# not this
raise Exception("panic!")
# this
from ansible import errors
...
raise errors.AnsibleError("panic!")
Similarly, exception checking should be fine grained:
# not this
try:
foo()
except:
bar()
# but this
try:
foo()
except SomeTypedException:
bar()
List Comprehensions
===================
In general list comprehensions are always preferred to map() and filter() calls.
However, they can be abused. Optimize for readability, and avoid nesting them too deeply.
Regexes
=======
There is a time and place for them, but here's an illustrative joke.
"A developer had a problem, and used a regular expression to solve it. Now the developer had two problems".
Often regexes are difficult to maintain, and a trusty call to other string operations can be a great solution, faster,
and more readable.
File Conventions
================
If a piece of code looks for a named YAML file in a directory, it should assume it can take no extension, or an extension of '.yml' or '.yaml'.
This should be true against all code that loads files.
Any code that uses directories should consider the possibility that the directory may be symlink.
New Ansible language parameters
===============================
If adding a new parameter, like 'can_fizzbuzz: True/False' be sure the value of the parameter is templated somewhere in the Runner code, as if anything can be parameterized in Ansible,
there is a user that will try to parameterize it.
String Find
===========
Use 'in':
# not this:
if x.find('foo') != -1:
# this:
if 'foo' in x:
String checks
=============
To test if something is a string, consider that it may be unicode.
# no
if type(x) == str:
# yes
from ansible.module_utils.six import string_types
if isinstance(x, string_types):
Cleverness
==========
Ansible's code is intended to be read by as many people as possible, so we don't particularly encourage clever or heavily idiomatic code.
In particular, metaclasses are probably not appropriate, however entertaining they may be to add.
Git Practices
=============
Pull requests cannot be accepted if they contain merge commits.
Always do "git pull --rebase" and "git rebase" vs "git pull" or "git merge". See [rebasing a pull request](https://docs.ansible.com/ansible/latest/dev_guide/developing_rebasing.html) for more information.
Always create a new branch for each pull request to avoid intermingling different features or fixes on the same branch.
Python Version Compliance
=========================
All code in Ansible core must support a minimum version of Python 2.6.
Module code must support a minimum of Python 2.4, with occasional exceptions for modules that require code that themselves require 2.6 and later.
A quick reminder is that list comprehensions in Python 2.4 are not as fully fleshed out, there are no 'dict' comprehensions, and there is no 'with' statement.
But otherwise it's pretty much all the same.
The End
=======
This was not meant to be a scary document, so we hope it wasn't, but we also hope this helps you write code that is easier to maintain by others in the future.
If you have questions about this document, please ask on the ansible-devel mailing list.
Thank you!
Our [Community Guide](https://docs.ansible.com/ansible/devel/community/) may also help you connect with the community of Ansible developers.

2
MODULE_GUIDELINES.md
View File

@ -1,3 +1,5 @@
# Module Maintainer Guidelines
The Ansible Module Maintainer Guidelines can now be found in the [official Ansible community guide](https://docs.ansible.com/ansible/latest/community/maintainers.html).
See also the [Developers Guide](https://docs.ansible.com/ansible/latest/dev_guide/)

63
README.rst
View File

@ -1,4 +1,4 @@
|PyPI version| |Docs badge| |Build Status|
|PyPI version| |Docs badge| |Chat badge| |Build Status|
*******
Ansible
@ -13,7 +13,7 @@ balancers.
Read the documentation and more at https://ansible.com/
You can find installation instructions
`here <https://docs.ansible.com/intro_getting_started.html>`_ for a
`here <https://docs.ansible.com/ansible/latest/installation_guide/intro_installation.html>`_ for a
variety of platforms.
Most users should probably install a released version of Ansible from ``pip``, a package manager or
@ -26,33 +26,30 @@ Ansible this way.
Design Principles
=================
* Have a dead simple setup process and a minimal learning curve
* Manage machines very quickly and in parallel
* Have a dead simple setup process and a minimal learning curve.
* Manage machines very quickly and in parallel.
* Avoid custom-agents and additional open ports, be agentless by
leveraging the existing SSH daemon
leveraging the existing SSH daemon.
* Describe infrastructure in a language that is both machine and human
friendly
* Focus on security and easy auditability/review/rewriting of content
friendly.
* Focus on security and easy auditability/review/rewriting of content.
* Manage new remote machines instantly, without bootstrapping any
software
* Allow module development in any dynamic language, not just Python
* Be usable as non-root
software.
* Allow module development in any dynamic language, not just Python.
* Be usable as non-root.
* Be the easiest IT automation system to use, ever.
Get Involved
============
* Read `Community
Information <https://docs.ansible.com/community.html>`_ for all
Information <https://docs.ansible.com/ansible/latest/community>`_ for all
kinds of ways to contribute to and interact with the project,
including mailing list information and how to submit bug reports and
code to Ansible.
* All code submissions are done through pull requests. Take care to
make sure no merge commits are in the submission, and use
``git rebase`` vs ``git merge`` for this reason. If submitting a
large code change (other than modules), it's probably a good idea to
join ansible-devel and talk about what you would like to do or add
first to avoid duplicate efforts. This not only helps everyone
* All code submissions are done through pull requests to the ``devel`` branch.
* Feel free to talk to us before making larger changes
to avoid duplicate efforts. This not only helps everyone
know what's going on, it also helps save time and effort if we decide
some changes are needed.
* Users list:
@ -63,17 +60,22 @@ Get Involved
`ansible-announce <https://groups.google.com/group/ansible-announce>`_
-- read only
* irc.freenode.net: #ansible
* For the full list of Email Lists, IRC channels see the
`Communication page <https://docs.ansible.com/ansible/latest/community/communication.html>`_
Branch Info
===========
* Releases are named after Led Zeppelin songs. (Releases prior to 2.0
were named after Van Halen songs.)
* The devel branch corresponds to the release actively under
* The ``devel`` branch corresponds to the release actively under
development.
* The ``stable-2.x`` branches exist for current releases.
* Various release-X.Y branches exist for previous releases.
* We'd love to have your contributions, read `Community
Information <https://docs.ansible.com/community.html>`_ for notes on
* For information about the active branches see the
`Ansible release and maintenance <https://docs.ansible.com/ansible/latest/reference_appendices/release_and_maintenance.html>`_ page.
* We'd love to have your contributions, read the `Community
Guide <https://docs.ansible.com/ansible/latest/community>`_ for notes on
how to get started.
Roadmap
@ -82,22 +84,7 @@ Roadmap
Based on team and community feedback, an initial roadmap will be published for a major or minor version (ex: 2.0, 2.1).
Subminor versions will generally not have roadmaps published.
Ansible 2.1 was the first release which published this and asked for feedback in this manner.
Feedback on the roadmap and the new process is quite welcome.
The team is aiming for further transparency and better inclusion of both community desires and submissions.
These are the team's *best guess* roadmaps based on the Ansible team's experience and are also based on requests and feedback from the community.
There are things that may not make it due to time constraints, lack of community maintainers, etc.
Each roadmap is published both as an idea of what is upcoming in Ansible, and as a medium for seeking further feedback from the community.
There are multiple places for you to submit feedback:
- Add to the agenda of an IRC `Core Team Meeting <https://github.com/ansible/community/blob/master/meetings/README.md>`_ (preferred)
- Ansible's google-group: ansible-devel
- AnsibleFest conferences
- IRC Freenode channel: #ansible-devel (this one may have things lost in lots of conversation)
For additional details consult the published `Ansible Roadmap <https://docs.ansible.com/ansible/devel/roadmap/>`_.
The `Ansible Roadmap page <https://docs.ansible.com/ansible/devel/roadmap/>`_ details what is planned and how to influence the roadmap.
Authors
=======
@ -119,6 +106,8 @@ See `COPYING <COPYING>`_ to see the full text.
.. |PyPI version| image:: https://img.shields.io/pypi/v/ansible.svg
:target: https://pypi.org/project/ansible
.. |Docs badge| image:: https://img.shields.io/badge/docs-latest-brightgreen.svg
:target: https://docs.ansible.com/ansible
:target: https://docs.ansible.com/ansible/latest/
.. |Build Status| image:: https://api.shippable.com/projects/573f79d02a8192902e20e34b/badge?branch=devel
:target: https://app.shippable.com/projects/573f79d02a8192902e20e34b
.. |Chat badge| image:: https://img.shields.io/badge/chat-IRC-brightgreen.svg
:target: https://docs.ansible.com/ansible/latest/community/communication.html

21
docs/docsite/rst/dev_guide/developing_modules_best_practices.rst
View File

@ -39,6 +39,16 @@ General guidelines & tips
* Avoid creating caches. Ansible is designed without a central server or authority, so you cannot guarantee it will not run with different permissions, options or locations. If you need a central authority, have it on top of Ansible (for example, using bastion/cm/ci server or tower); do not try to build it into modules.
* If you package your module(s) in an RPM, install the modules on the control machine in ``/usr/share/ansible``. Packaging modules in RPMs is optional.
Functions and Methods
=====================
* Each function should be concise and should describe a meaningful amount of work.
* "Don't repeat yourself" is generally a good philosophy.
* Function names should use underscores: ``my_function_name``.
* Each function's name should describes what it does.
* Each function should have a docstring.
* If your code is too nested, that's usually a sign the loop body could benefit from being a function. Parts of our existing code are not the best examples of this at times.
Python tips
===========
@ -148,3 +158,14 @@ Ansible conventions offer a predictable user interface across all modules, playb
* Strive for a consistent final state (aka idempotency). If running your module twice in a row against the same system would result in two different states, see if you can redesign or rewrite to achieve consistent final state. If you can't, document the behavior and the reasons for it.
* Provide consistent return values within the standard Ansible return structure, even if NA/None are used for keys normally returned under other options.
* Follow additional guidelines that apply to families of modules if applicable. For example, AWS modules should follow `the Amazon guidelines <https://github.com/ansible/ansible/blob/devel/lib/ansible/modules/cloud/amazon/GUIDELINES.md>`_
Module Security
===============
* Avoid passing user input from the shell.
* Always check return codes.
* You must always use ``module.run_command``, not ``subprocess`` or ``Popen`` or ``os.system``.
* Avoid using the shell unless absolutely necessary.
* If you must use the shell, you must pass ``use_unsafe_shell=True`` to ``module.run_command``.
* If any variables in your module can come from user input with ``use_unsafe_shell=True``, you must wrap them with ``pipes.quote(x)``.
* When fetching URLs, use ``fetch_url`` or ``open_url`` from ``ansible.module_utils.urls``. Do not use ``urllib2``, which does not natively verify TLS certificates and so is insecure for https.

1
docs/docsite/rst/dev_guide/developing_modules_checklist.rst
View File

@ -23,6 +23,7 @@ To contribute a module to Ansible, you must:
* include comprehensive :ref:`tests <developing_testing>` for your module
* minimize module dependencies
* support :ref:`check_mode <check_mode_dry>` if possible
* ensure your code is readable
Please make sure your module meets these requirements before you submit your PR/proposal. If you have questions, reach out via `Ansible's IRC chat channel <http://irc.freenode.net>`_ or the `Ansible development mailing list <https://groups.google.com/group/ansible-devel>`_.

17
docs/docsite/rst/roadmap/index.rst
View File

@ -3,7 +3,21 @@
Ansible Roadmap
===============
The Ansible team develops a roadmap for each major Ansible release. The latest roadmap shows current work; older roadmaps provide a history of the project.
The Ansible team develops a roadmap for each major and minor Ansible release. The latest roadmap shows current work; older roadmaps provide a history of the project. We don't publish roadmaps for subminor versions. So 2.0 and 2.8 have roadmaps, but 2.7.1 does not.
We incorporate team and community feedback in each roadmap, and aim for further transparency and better inclusion of both community desires and submissions.
Each roadmap offers a *best guess*, based on the Ansible team's experience and on requests and feedback from the community, of what will be included in a given release. However, some items on the roadmap may be dropped due to time constraints, lack of community maintainers, etc.
Each roadmap is published both as an idea of what is upcoming in Ansible, and as a medium for seeking further feedback from the community.
You can submit feedback on the current roadmap in multiple ways:
- Edit the agenda of an IRC `Core Team Meeting <https://github.com/ansible/community/blob/master/meetings/README.md>`_ (preferred)
- Post on the ``#ansible-devel`` Freenode IRC channel
- Email the ansible-devel list
See :ref:`Ansible communication channels <communication>` for details on how to join and use the email lists and IRC channels.
.. toctree::
:maxdepth: 1
@ -11,4 +25,3 @@ The Ansible team develops a roadmap for each major Ansible release. The latest r
:caption: Ansible Release Roadmaps
ROADMAP*