cmueller/ansible
1
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

[stable-2.7] bulk docs update (#47828)

Browse source 
* Document all Working Group, email lists and IRC channels (#47615)

(cherry picked from commit 749af9fd22)

* Docs: No need to follow up on backport PRs (#47616)

(cherry picked from commit 166e84b9c4)

* Tidy up Contributors Docs (#47619)

(cherry picked from commit 72359a10e6)

* Correct AWX community link (#47742)

(cherry picked from commit d189e58f63)

* ansible-lint and molecule part of Red Hat (#47826)

(cherry picked from commit 4572d9ccd7)
This commit is contained in:
John R Barker 2018-10-30 19:45:41 +00:00 committed by Alicia Cozine
parent aaae3eb2c1
commit 39e959eb0c
10 changed files with 136 additions and 402 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

65
docs/docsite/rst/community/communication.rst
View file

@ -4,7 +4,8 @@
Communicating
*************
.. contents:: Topics
.. contents::
:local:
Code of Conduct
===============
@ -16,50 +17,64 @@ Mailing list information
Ansible has several mailing lists. Your first post to the mailing list will be moderated (to reduce spam), so please allow up to a day or so for your first post to appear.
`Ansible Project List <https://groups.google.com/forum/#!forum/ansible-project>`_ is for sharing Ansible tips, answering questions, and general user discussion.
* `Ansible Announce list <https://groups.google.com/forum/#!forum/ansible-announce>`_ is a read-only list that shares information about new releases of Ansible, and also rare infrequent event information, such as announcements about an upcoming AnsibleFest, which is our official conference series. Worth subscribing to!
* `Ansible AWX List <https://groups.google.com/forum/#!forum/awx-project>`_ is for `Ansible AWX <https://github.com/ansible/awx>`_ the upstream version of `Ansible Tower <https://www.ansible.com/products/tower>`_
* `Ansible Container List <https://groups.google.com/forum/#!forum/ansible-container>`_ is for users and developers of the Ansible Container project.
* `Ansible Development List <https://groups.google.com/forum/#!forum/ansible-devel>`_ 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 <https://groups.google.com/forum/#!forum/ansible-lockdown>`_ is for all things related to Ansible Lockdown projects, including DISA STIG automation and CIS Benchmarks.
* `Ansible Outreach List <https://groups.google.com/forum/#!forum/ansible-outreach>`_ help with promoting Ansible and `Ansible Meetups <http://ansible.meetup.com/>`_
* `Ansible Project List <https://groups.google.com/forum/#!forum/ansible-project>`_ is for sharing Ansible tips, answering questions, and general user discussion.
* `Molecule List <https://groups.google.com/forum/#!forum/molecule-users>`_ is designed to aid with the development and testing of Ansible roles with Molecule.
`Ansible Development List <https://groups.google.com/forum/#!forum/ansible-devel>`_ is for learning how to develop on Ansible, asking about prospective feature design, or discussions about extending ansible or features in progress.
`Ansible Announce list <https://groups.google.com/forum/#!forum/ansible-announce>`_ is a read-only list that shares information about new releases of Ansible, and also rare infrequent event information, such as announcements about an upcoming AnsibleFest, which is our official conference series.
`Ansible Container List <https://groups.google.com/forum/#!forum/ansible-container>`_ is for users and developers of the Ansible Container project.
`Ansible Lockdown List <https://groups.google.com/forum/#!forum/ansible-lockdown>`_ is for all things related to Ansible Lockdown projects, including DISA STIG automation and CIS Benchmarks.
To subscribe to a group from a non-Google account, you can send an email to the subscription address requesting the subscription. For example: `ansible-devel+subscribe@googlegroups.com`
To subscribe to a group from a non-Google account, you can send an email to the subscription address requesting the subscription. For example: ``ansible-devel+subscribe@googlegroups.com``
IRC channels
============
Ansible has several IRC channels on Freenode (irc.freenode.net).
Ansible has several IRC channels on `Freenode <https://freenode.net/>`_.
Our IRC channels may require you to register your nickname. If you receive an error when you connect, see `Freenode's Nickname Registration guide <https://freenode.net/kb/answer/registration>`_ for instructions.
General channels
----------------
- ``#ansible`` - For general use questions and support.
- ``#ansible-devel`` - For discussions on developer topics and code related to features/bugs.
- ``#ansible-devel`` - For discussions on developer topics and code related to features or bugs.
- ``#ansible-meeting`` - For public community meetings. We will generally announce these on one or more of the above mailing lists. See the `meeting schedule and agenda page <https://github.com/ansible/community/blob/master/meetings/README.md>`_
- ``#ansible-notices`` - Mostly bot output from things like GitHub, etc.
Working groups
--------------
- ``#ansible-aws`` - For discussions on Amazon Web Services.
- ``#ansible-community`` - Channel for discussing Ansible Community related things.
- ``#ansible-container`` - For discussions on Ansible Container.
- ``#ansible-jboss`` - Channel for discussing JBoss and Ansible related things.
- ``#ansible-network`` - Channel for discussing Network and Ansible related things.
- ``#ansible-news`` - Channel for discussing Ansible Communication & News related things.
- ``#ansible-vmware`` - For discussions on Ansible & VMware.
- ``#ansible-windows`` - For discussions on Ansible & Windows.
Many of our community Working Groups meet on Freenode IRC channels. If you want to get involved in a working group, join the channel where it meets.
- `Amazon (AWS) Working Group <https://github.com/ansible/community/tree/master/group-aws>`_ - ``#ansible-aws``
- `Ansible Lockdown Working Group <https://ansiblelockdown.io>`_ `gh/ansible/ansible-lockdown <https://github.com/ansible/ansible-lockdown>`_ - ``#ansible-lockdown``- Security playbooks/roles
- `AWX Working Group <https://github.com/ansible/awx>`_ - ``#ansible-awx`` - Upstream Ansible Tower
- `Azure Working Group <https://github.com/ansible/community/tree/master/group-azure>`_ - ``#ansible-azure``
- `Community Working Group <https://github.com/ansible/community/tree/master/group-community>`_ - ``#ansible-community`` - Including Meetups
- `Container Working Group <https://github.com/ansible/community/tree/master/group-container>`_ - ``#ansible-container``
- `Contributor Experience Working Group <https://github.com/ansible/community/tree/master/group-contributor-experience>`_ - ``#ansible-community``
- `Docker Working Group <https://github.com/ansible/community/issues/379>`_ - ``#ansible-devel``
- `Documentation Working Group <https://github.com/ansible/community/tree/master/group-docs>`_- ``#ansible-docs``
- `Galaxy Working Group <https://github.com/ansible/community/tree/master/group-galaxy>`_ - ``#ansible-galaxy``
- `JBoss Working Group <https://github.com/ansible/community/tree/master/group-jboss>`_ - ``#ansible-jboss``
- `Lightbulb Training <https://github.com/ansible/lightbulb>`_ - ``#ansible-lightbulb`` - Ansible training
- `Linode Working Group <https://github.com/ansible/community/tree/master/group-linode>`_ - ``#ansible-linode``
- `Molecule <https://molecule.readthedocs.io>`_ - ``#molecule-users`` - testing platform for Ansible playbooks and roles
- `Network Working Group <https://github.com/ansible/community/tree/master/group-network>`_ - ``#ansible-network``
- `Testing Working Group <https://github.com/ansible/community/tree/master/group-testing>`_ - ``#ansible-devel``
- `VMware Working Group <https://github.com/ansible/community/tree/master/group-vmware>`_ - ``#ansible-vmware``
- `Windows Working Group <https://github.com/ansible/community/tree/master/group-windows>`_ - ``#ansible-windows``
Language-specific channels
--------------------------
Want to `form a new Working Group <https://github.com/ansible/community/blob/master/WORKING-GROUPS.md>`_?
Regional and Language-specific channels
---------------------------------------
- ``#ansible-es`` - Channel for Spanish speaking Ansible community.
- ``#ansibleu`` - Channel for the European Ansible Community.
- ``#ansible-fr`` - Channel for French speaking Ansible community.
- ``#ansiblezh`` - Channel for Zurich/Swiss Ansible community.
IRC meetings
------------

38
docs/docsite/rst/community/development_process.rst
View file

@ -4,7 +4,8 @@
The Ansible Development Process
*******************************
.. contents:: Topics
.. contents::
:local:
This section discusses how the Ansible development and triage process works.
@ -35,29 +36,26 @@ After the pull request submitted to Ansible for the ``devel`` branch is
accepted and merged, the following instructions will help you create a
pull request to backport the change to a previous stable branch.
.. note::
These instructions assume that ``stable-2.5`` is the targeted release
branch for the backport.
We do **not** backport features.
.. note::
These instructions assume that ``https://github.com/ansible/ansible.git``
is configured as a ``git remote`` named ``upstream``. If you do not use
a ``git remote`` named ``upstream``, adjust the instructions accordingly.
These instructions assume that:
.. note::
These instructions assume that ``https://github.com/<yourgithubaccount>/ansible.git``
is configured as a ``git remote`` named ``origin``. If you do not use
a ``git remote`` named ``origin``, adjust the instructions accordingly.
* ``stable-2.7`` is the targeted release branch for the backport
* ``https://github.com/ansible/ansible.git`` is configured as a
``git remote`` named ``upstream``. If you do not use
a ``git remote`` named ``upstream``, adjust the instructions accordingly.
* ``https://github.com/<yourgithubaccount>/ansible.git``
is configured as a ``git remote`` named ``origin``. If you do not use
a ``git remote`` named ``origin``, adjust the instructions accordingly.
#. Prepare your devel, stable, and feature branches:
::
git fetch upstream
git checkout -b backport/2.5/[PR_NUMBER_FROM_DEVEL] upstream/stable-2.5
git checkout -b backport/2.7/[PR_NUMBER_FROM_DEVEL] upstream/stable-2.7
#. Cherry pick the relevant commit SHA from the devel branch into your feature
branch, handling merge conflicts as necessary:
@ -72,14 +70,18 @@ pull request to backport the change to a previous stable branch.
::
git push origin backport/2.5/[PR_NUMBER_FROM_DEVEL]
git push origin backport/2.7/[PR_NUMBER_FROM_DEVEL]
#. Submit the pull request for ``backport/2.5/[PR_NUMBER_FROM_DEVEL]``
against the ``stable-2.5`` branch
#. Submit the pull request for ``backport/2.7/[PR_NUMBER_FROM_DEVEL]``
against the ``stable-2.7`` branch
#. The Release Manager will decide whether to merge the backport PR before
the next minor release. There isn't any need to follow up. Just ensure that the automated
tests (CI) are green.
.. note::
The choice to use ``backport/2.5/[PR_NUMBER_FROM_DEVEL]`` as the
The choice to use ``backport/2.7/[PR_NUMBER_FROM_DEVEL]`` as the
name for the feature branch is somewhat arbitrary, but conveys meaning
about the purpose of that branch. It is not required to use this format,
but it can be helpful, especially when making multiple backport PRs for

4
docs/docsite/rst/community/other_tools_and_programs.rst
View file

@ -87,9 +87,9 @@ There are various ways to find existing issues and pull requests (PRs)
Tools for Validating Playbooks
******************************
- `Ansible Lint <https://github.com/willthames/ansible-lint>`_ - widely used, highly configurable best-practices linter for Ansible playbooks.
- `Ansible Lint <https://github.com/ansible/ansible-lint>`_ - the official, highly configurable best-practices linter for Ansible playbooks, by Ansible.
- `Ansible Review <https://github.com/willthames/ansible-review>`_ - an extension of Ansible Lint designed for code review.
- `Molecule <https://github.com/metacloud/molecule>`_ is a testing framework for Ansible plays and roles.
- `Molecule <https://github.com/ansible/molecule>`_ is a testing framework for Ansible plays and roles, by Ansible
- `yamllint <https://yamllint.readthedocs.io/en/stable/>`__ is a command-line utility to check syntax validity including key repetition and indentation issues.

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
===========
@ -141,3 +151,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*