Rebased pr73824 (#73934)
Co-authored-by: Eugene <k.evgen61@gmail.com> Co-authored-by: Alicia Cozine <acozine@users.noreply.github.com>
This commit is contained in:
Alicia Cozine
GitHub
parent
4add723107
commit
b57444af14
23 changed files with 50 additions and 47 deletions
|
|
@ -196,7 +196,7 @@ config: ../templates/config.rst.j2
|
|||
plugins:
|
||||
$(PLUGIN_FORMATTER) full -o rst $(ANSIBLE_VERSION_ARGS) $(PLUGIN_ARGS);\
|
||||
|
||||
# This only builds the plugin docs included with ansible-base
|
||||
# This only builds the plugin docs included with ansible-core
|
||||
base_plugins:
|
||||
$(PLUGIN_FORMATTER) base -o rst $(PLUGIN_ARGS);\
|
||||
|
||||
|
|
|
|||
|
|
@ -61,7 +61,7 @@ Individuals with direct commit access to ansible/ansible are entrusted with powe
|
|||
- 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 ``ansible-base`` against which this documentation is compatible (to avoid confusion between stable and devel docs, for backwards compatibility, and so on).
|
||||
- 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 ``ansible-core`` against which this documentation is compatible (to avoid confusion between stable and devel docs, for backwards compatibility, and so on).
|
||||
- Consider scope, sometimes a fix can be generalized
|
||||
- Keep it simple, then things are maintainable, debuggable and intelligible.
|
||||
|
||||
|
|
|
|||
|
|
@ -4,19 +4,19 @@
|
|||
The Ansible Development Cycle
|
||||
*****************************
|
||||
|
||||
Ansible developers (including community contributors) add new features, fix bugs, and update code in many different repositories. The `ansible/ansible repository <https://github.com/ansible/ansible>`_ contains the code for basic features and functions, such as copying module code to managed nodes. This code is also known as ``ansible-base``. Other repositories contain plugins and modules that enable Ansible to execute specific tasks, like adding a user to a particular database or configuring a particular network device. These repositories contain the source code for collections.
|
||||
Ansible developers (including community contributors) add new features, fix bugs, and update code in many different repositories. The `ansible/ansible repository <https://github.com/ansible/ansible>`_ contains the code for basic features and functions, such as copying module code to managed nodes. This code is also known as ``ansible-core``. Other repositories contain plugins and modules that enable Ansible to execute specific tasks, like adding a user to a particular database or configuring a particular network device. These repositories contain the source code for collections.
|
||||
|
||||
Development on ``ansible-base`` occurs on two levels. At the macro level, the ``ansible-base`` developers and maintainers plan releases and track progress with roadmaps and projects. At the micro level, each PR has its own lifecycle.
|
||||
Development on ``ansible-core`` occurs on two levels. At the macro level, the ``ansible-core`` developers and maintainers plan releases and track progress with roadmaps and projects. At the micro level, each PR has its own lifecycle.
|
||||
|
||||
Development on collections also occurs at the macro and micro levels. Each collection has its own macro development cycle. For more information on the collections development cycle, see :ref:`contributing_maintained_collections`. The micro-level lifecycle of a PR is similar in collections and in ``ansible-base``.
|
||||
Development on collections also occurs at the macro and micro levels. Each collection has its own macro development cycle. For more information on the collections development cycle, see :ref:`contributing_maintained_collections`. The micro-level lifecycle of a PR is similar in collections and in ``ansible-core``.
|
||||
|
||||
.. contents::
|
||||
:local:
|
||||
|
||||
Macro development: ``ansible-base`` roadmaps, releases, and projects
|
||||
Macro development: ``ansible-core`` roadmaps, releases, and projects
|
||||
=====================================================================
|
||||
|
||||
If you want to follow the conversation about what features will be added to ``ansible-base`` for upcoming releases and what bugs are being fixed, you can watch these resources:
|
||||
If you want to follow the conversation about what features will be added to ``ansible-core`` for upcoming releases and what bugs are being fixed, you can watch these resources:
|
||||
|
||||
* the :ref:`roadmaps`
|
||||
* the :ref:`Ansible Release Schedule <release_and_maintenance>`
|
||||
|
|
@ -31,7 +31,7 @@ If you want to follow the conversation about what features will be added to ``an
|
|||
Micro development: the lifecycle of a PR
|
||||
========================================
|
||||
|
||||
If you want to contribute a feature or fix a bug in ``ansible-base`` or in a collection, you must open a **pull request** ("PR" for short). GitHub provides a great overview of `how the pull request process works <https://help.github.com/articles/about-pull-requests/>`_ in general. The ultimate goal of any pull request is to get merged and become part of a collection or ``ansible-base``.
|
||||
If you want to contribute a feature or fix a bug in ``ansible-core`` or in a collection, you must open a **pull request** ("PR" for short). GitHub provides a great overview of `how the pull request process works <https://help.github.com/articles/about-pull-requests/>`_ in general. The ultimate goal of any pull request is to get merged and become part of a collection or ``ansible-core``.
|
||||
Here's an overview of the PR lifecycle:
|
||||
|
||||
* Contributor opens a PR
|
||||
|
|
@ -143,7 +143,7 @@ We do not merge every PR. Here are some tips for making your PR useful, attracti
|
|||
Changelogs
|
||||
----------
|
||||
|
||||
Changelogs help users and developers keep up with changes to Ansible. Ansible builds a changelog for each release from fragments. You **must** add a changelog fragment to any PR that changes functionality or fixes a bug in ansible-base. You do not have to add a changelog fragment for PRs that add new modules and plugins, because our tooling does that for you automatically.
|
||||
Changelogs help users and developers keep up with changes to Ansible. Ansible builds a changelog for each release from fragments. You **must** add a changelog fragment to any PR that changes functionality or fixes a bug in ansible-core. You do not have to add a changelog fragment for PRs that add new modules and plugins, because our tooling does that for you automatically.
|
||||
|
||||
We build short summary changelogs for minor releases as well as for major releases. If you backport a bugfix, include a changelog fragment with the backport PR.
|
||||
|
||||
|
|
@ -212,10 +212,10 @@ After you have written the changelog fragment for your PR, commit the file and i
|
|||
|
||||
.. _backport_process:
|
||||
|
||||
Backporting merged PRs in ``ansible-base``
|
||||
Backporting merged PRs in ``ansible-core``
|
||||
===========================================
|
||||
|
||||
All ``ansible-base`` PRs must be merged to the ``devel`` branch first. After a pull request has been accepted and merged to the ``devel`` branch, the following instructions will help you create a pull request to backport the change to a previous stable branch.
|
||||
All ``ansible-core`` PRs must be merged to the ``devel`` branch first. After a pull request has been accepted and merged to the ``devel`` branch, the following instructions will help you create a pull request to backport the change to a previous stable branch.
|
||||
|
||||
We do **not** backport features.
|
||||
|
||||
|
|
|
|||
|
|
@ -52,7 +52,7 @@ Going deeper
|
|||
Working with the Ansible repo
|
||||
=============================
|
||||
|
||||
* I want to make my first code changes to a collection or to ``ansible-base``. How do I :ref:`set up my Python development environment <environment_setup>`?
|
||||
* I want to make my first code changes to a collection or to ``ansible-core``. How do I :ref:`set up my Python development environment <environment_setup>`?
|
||||
* I would like to get more efficient as a developer. How can I find :ref:`editors, linters, and other tools <other_tools_and_programs>` that will support my Ansible development efforts?
|
||||
* I want my code to meet Ansible's guidelines. Where can I find guidance on :ref:`coding in Ansible <developer_guide>`?
|
||||
* I want to learn more about Ansible roadmaps, releases, and projects. How do I find information on :ref:`the development cycle <community_development_process>`?
|
||||
|
|
|
|||
|
|
@ -17,7 +17,7 @@ Security bugs
|
|||
|
||||
Ansible practices responsible disclosure - if this is a security-related bug, email `security@ansible.com <mailto:security@ansible.com>`_ instead of filing a ticket or posting to any public groups, and you will receive a prompt response.
|
||||
|
||||
Bugs in ansible-base
|
||||
Bugs in ansible-core
|
||||
--------------------
|
||||
|
||||
If you find a bug that affects multiple plugins, a plugin that remained in the ansible/ansible repo, or the overall functioning of Ansible, report it to `github.com/ansible/ansible/issues <https://github.com/ansible/ansible/issues>`_. You need a free GitHub account. Before reporting a bug, use the bug/issue search to see if the issue has already been reported. If you are not sure if something is a bug yet, you can report the behavior on the :ref:`mailing list or IRC first <communication>`.
|
||||
|
|
@ -46,11 +46,11 @@ Many bugs only affect a single module or plugin. If you find a bug that affects
|
|||
#. Click on the Issue Tracker link for that collection.
|
||||
#. Follow the contributor guidelines or instructions in the collection repo.
|
||||
|
||||
If you are not sure whether a bug is in ansible-base or in a collection, you can report the behavior on the :ref:`mailing list or IRC first <communication>`.
|
||||
If you are not sure whether a bug is in ansible-core or in a collection, you can report the behavior on the :ref:`mailing list or IRC first <communication>`.
|
||||
|
||||
.. _request_features:
|
||||
|
||||
Requesting a feature
|
||||
====================
|
||||
|
||||
The best way to get a feature into Ansible is to :ref:`submit a pull request <community_pull_requests>`, either against ansible-base or against a collection. See also :ref:`ansible_collection_merge_requirements`.
|
||||
The best way to get a feature into Ansible is to :ref:`submit a pull request <community_pull_requests>`, either against ansible-core or against a collection. See also :ref:`ansible_collection_merge_requirements`.
|
||||
|
|
|
|||
|
|
@ -651,7 +651,7 @@ The build process for docs.ansible.com will know where to find the module docs.
|
|||
Testing collections
|
||||
===================
|
||||
|
||||
The main tool for testing collections is ``ansible-test``, Ansible's testing tool described in :ref:`developing_testing`. You can run several compile and sanity checks, as well as run unit and integration tests for plugins using ``ansible-test``. When you test collections, test against the ansible-base version(s) you are targeting.
|
||||
The main tool for testing collections is ``ansible-test``, Ansible's testing tool described in :ref:`developing_testing`. You can run several compile and sanity checks, as well as run unit and integration tests for plugins using ``ansible-test``. When you test collections, test against the ansible-core version(s) you are targeting.
|
||||
|
||||
You must always execute ``ansible-test`` from the root directory of a collection. You can run ``ansible-test`` in Docker containers without installing any special requirements. The Ansible team uses this approach in Shippable both in the ansible/ansible GitHub repository and in the large community collections such as `community.general <https://github.com/ansible-collections/community.general/>`_ and `community.network <https://github.com/ansible-collections/community.network/>`_. The examples below demonstrate running tests in Docker containers.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,8 +1,8 @@
|
|||
***************************
|
||||
Developing ``ansible-base``
|
||||
Developing ``ansible-core``
|
||||
***************************
|
||||
|
||||
Although ``ansible-base`` (the code hosted in the `ansible/ansible repository <https://github.com/ansible/ansible>`_ on GitHub) includes a few plugins that can be swapped out via playbook directives or configuration, much of the code there is not modular. The documents here give insight into how the parts of ``ansible-base`` work together.
|
||||
Although ``ansible-core`` (the code hosted in the `ansible/ansible repository <https://github.com/ansible/ansible>`_ on GitHub) includes a few plugins that can be swapped out via playbook directives or configuration, much of the code there is not modular. The documents here give insight into how the parts of ``ansible-core`` work together.
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
|
|
|||
|
|
@ -31,8 +31,8 @@ Designing module interfaces
|
|||
General guidelines & tips
|
||||
=========================
|
||||
|
||||
* Each module should be self-contained in one file, so it can be auto-transferred by ``ansible-base``.
|
||||
* Module name MUST use underscores instead of hyphens or spaces as a word separator. Using hyphens and spaces will prevent ``ansible-base`` from importing your module.
|
||||
* Each module should be self-contained in one file, so it can be auto-transferred by ``ansible-core``.
|
||||
* Module name MUST use underscores instead of hyphens or spaces as a word separator. Using hyphens and spaces will prevent ``ansible-core`` from importing your module.
|
||||
* Always use the ``hacking/test-module.py`` script when developing modules - it will warn you about common pitfalls.
|
||||
* If you have a local module that returns information specific to your installations, a good name for this module is ``site_info``.
|
||||
* Eliminate or minimize dependencies. If your module has dependencies, document them at the top of the module file and raise JSON error messages when dependency import fails.
|
||||
|
|
|
|||
|
|
@ -198,7 +198,7 @@ All fields in the ``DOCUMENTATION`` block are lower-case. All fields are require
|
|||
:seealso:
|
||||
|
||||
* A list of references to other modules, documentation or Internet resources
|
||||
* In Ansible 2.10 and later, references to modules must use the FQCN or ``ansible.builtin`` for modules in ``ansible-base``.
|
||||
* In Ansible 2.10 and later, references to modules must use the FQCN or ``ansible.builtin`` for modules in ``ansible-core``.
|
||||
* A reference can be one of the following formats:
|
||||
|
||||
|
||||
|
|
@ -341,7 +341,7 @@ Per playbook best practices, each example should include a ``name:`` line::
|
|||
|
||||
The ``name:`` line should be capitalized and not include a trailing dot.
|
||||
|
||||
Use a fully qualified collection name (FQCN) as a part of the module's name like in the example above. For modules in ``ansible-base``, use the ``ansible.builtin.`` identifier, for example ``ansible.builtin.debug``.
|
||||
Use a fully qualified collection name (FQCN) as a part of the module's name like in the example above. For modules in ``ansible-core``, use the ``ansible.builtin.`` identifier, for example ``ansible.builtin.debug``.
|
||||
|
||||
If your examples use boolean options, use yes/no values. Since the documentation generates boolean values as yes/no, having the examples use these values as well makes the module documentation more consistent.
|
||||
|
||||
|
|
|
|||
|
|
@ -196,7 +196,7 @@ test/units/modules/.../test/my_test.py``
|
|||
Contributing back to Ansible
|
||||
============================
|
||||
|
||||
If you would like to contribute to ``ansible-base`` by adding a new feature or fixing a bug, `create a fork <https://help.github.com/articles/fork-a-repo/>`_ of the ansible/ansible repository and develop against a new feature branch using the ``devel`` branch as a starting point. When you have a good working code change, you can submit a pull request to the Ansible repository by selecting your feature branch as a source and the Ansible devel branch as a target.
|
||||
If you would like to contribute to ``ansible-core`` by adding a new feature or fixing a bug, `create a fork <https://help.github.com/articles/fork-a-repo/>`_ of the ansible/ansible repository and develop against a new feature branch using the ``devel`` branch as a starting point. When you have a good working code change, you can submit a pull request to the Ansible repository by selecting your feature branch as a source and the Ansible devel branch as a target.
|
||||
|
||||
If you want to contribute a module to an :ref:`Ansible collection <contributing_maintained_collections>`, review our :ref:`submission checklist <developing_modules_checklist>`, :ref:`programming tips <developing_modules_best_practices>`, and :ref:`strategy for maintaining Python 2 and Python 3 compatibility <developing_python_3>`, as well as information about :ref:`testing <developing_testing>` before you open a pull request.
|
||||
|
||||
|
|
|
|||
|
|
@ -14,7 +14,7 @@ Starting with Ansible 2.10, related modules should be developed in a collection.
|
|||
Before you start coding
|
||||
=======================
|
||||
|
||||
This list of prerequisites is designed to help ensure that you develop high-quality modules that work well with ansible-base and provide a seamless user experience.
|
||||
This list of prerequisites is designed to help ensure that you develop high-quality modules that work well with ansible-core and provide a seamless user experience.
|
||||
|
||||
* Read though all the pages linked off :ref:`developing_modules_general`; paying particular focus to the :ref:`developing_modules_checklist`.
|
||||
* We encourage PEP 8 compliance. See :ref:`testing_pep8` for more information.
|
||||
|
|
|
|||
|
|
@ -278,7 +278,7 @@ Note that the ``CALLBACK_VERSION`` and ``CALLBACK_NAME`` definitions are require
|
|||
|
||||
For example callback plugins, see the source code for the `callback plugins included with Ansible Core <https://github.com/ansible/ansible/tree/devel/lib/ansible/plugins/callback>`_
|
||||
|
||||
New in ansible-base 2.11, callback plugins are notified (via ``v2_playbook_on_task_start``) of :ref:`meta<meta_module>` tasks. By default, only explicit ``meta`` tasks that users list in their plays are sent to callbacks.
|
||||
New in ansible-core 2.11, callback plugins are notified (via ``v2_playbook_on_task_start``) of :ref:`meta<meta_module>` tasks. By default, only explicit ``meta`` tasks that users list in their plays are sent to callbacks.
|
||||
|
||||
There are also some tasks which are generated internally and implicitly at various points in execution. Callback plugins can opt-in to receiving these implicit tasks as well, by setting ``self.wants_implicit_tasks = True``. Any ``Task`` object received by a callback hook will have an ``.implicit`` attribute, which can be consulted to determine whether the ``Task`` originated from within Ansible, or explicitly by the user.
|
||||
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@
|
|||
Ansible module architecture
|
||||
***************************
|
||||
|
||||
If you are working on the ``ansible-base`` code, writing an Ansible module, or developing an action plugin, you may need to understand how Ansible's program flow executes. If you are just using Ansible Modules in playbooks, you can skip this section.
|
||||
If you are working on the ``ansible-core`` code, writing an Ansible module, or developing an action plugin, you may need to understand how Ansible's program flow executes. If you are just using Ansible Modules in playbooks, you can skip this section.
|
||||
|
||||
.. contents::
|
||||
:local:
|
||||
|
|
@ -631,7 +631,7 @@ This section will discuss the behavioral attributes for arguments:
|
|||
|
||||
:removed_in_version:
|
||||
|
||||
``removed_in_version`` indicates which version of ansible-base or a collection a deprecated argument will be removed in. Mutually exclusive with ``removed_at_date``, and must be used with ``removed_from_collection``.
|
||||
``removed_in_version`` indicates which version of ansible-core or a collection a deprecated argument will be removed in. Mutually exclusive with ``removed_at_date``, and must be used with ``removed_from_collection``.
|
||||
|
||||
Example:
|
||||
|
||||
|
|
@ -645,7 +645,7 @@ This section will discuss the behavioral attributes for arguments:
|
|||
|
||||
:removed_at_date:
|
||||
|
||||
``removed_at_date`` indicates that a deprecated argument will be removed in a minor ansible-base release or major collection release after this date. Mutually exclusive with ``removed_in_version``, and must be used with ``removed_from_collection``.
|
||||
``removed_at_date`` indicates that a deprecated argument will be removed in a minor ansible-core release or major collection release after this date. Mutually exclusive with ``removed_in_version``, and must be used with ``removed_from_collection``.
|
||||
|
||||
Example:
|
||||
|
||||
|
|
@ -659,7 +659,7 @@ This section will discuss the behavioral attributes for arguments:
|
|||
|
||||
:removed_from_collection:
|
||||
|
||||
Specifies which collection (or ansible-base) deprecates this deprecated argument. Specify ``ansible.builtin`` for ansible-base, or the collection's name (format ``foo.bar``). Must be used with ``removed_in_version`` or ``removed_at_date``.
|
||||
Specifies which collection (or ansible-core) deprecates this deprecated argument. Specify ``ansible.builtin`` for ansible-core, or the collection's name (format ``foo.bar``). Must be used with ``removed_in_version`` or ``removed_at_date``.
|
||||
|
||||
:deprecated_aliases:
|
||||
|
||||
|
|
@ -671,15 +671,15 @@ This section will discuss the behavioral attributes for arguments:
|
|||
|
||||
:version:
|
||||
|
||||
The version of ansible-base or the collection this alias will be removed in. Either ``version`` or ``date`` must be specified.
|
||||
The version of ansible-core or the collection this alias will be removed in. Either ``version`` or ``date`` must be specified.
|
||||
|
||||
:date:
|
||||
|
||||
The a date after which a minor release of ansible-base or a major collection release will no longer contain this alias.. Either ``version`` or ``date`` must be specified.
|
||||
The a date after which a minor release of ansible-core or a major collection release will no longer contain this alias.. Either ``version`` or ``date`` must be specified.
|
||||
|
||||
:collection_name:
|
||||
|
||||
Specifies which collection (or ansible-base) deprecates this deprecated alias. Specify ``ansible.builtin`` for ansible-base, or the collection's name (format ``foo.bar``). Must be used with ``version`` or ``date``.
|
||||
Specifies which collection (or ansible-core) deprecates this deprecated alias. Specify ``ansible.builtin`` for ansible-core, or the collection's name (format ``foo.bar``). Must be used with ``version`` or ``date``.
|
||||
|
||||
Examples:
|
||||
|
||||
|
|
|
|||
|
|
@ -4,8 +4,8 @@
|
|||
Ansible and Python 3
|
||||
********************
|
||||
|
||||
The ``ansible-base`` code runs on both Python 2 and Python 3 because we want Ansible to be able to manage a wide
|
||||
variety of machines. Contributors to ansible-base and to Ansible Collections should be aware of the tips in this document so that they can write code that will run on the same versions of Python as the rest of Ansible.
|
||||
The ``ansible-core`` code runs on both Python 2 and Python 3 because we want Ansible to be able to manage a wide
|
||||
variety of machines. Contributors to ansible-core and to Ansible Collections should be aware of the tips in this document so that they can write code that will run on the same versions of Python as the rest of Ansible.
|
||||
|
||||
.. contents::
|
||||
:local:
|
||||
|
|
|
|||
|
|
@ -3,5 +3,5 @@ runtime-metadata.yml
|
|||
|
||||
Validates the schema for:
|
||||
|
||||
* ansible-base's ``lib/ansible/config/ansible_builtin_runtime.yml``
|
||||
* ansible-core's ``lib/ansible/config/ansible_builtin_runtime.yml``
|
||||
* collection's ``meta/runtime.yml``
|
||||
|
|
|
|||
|
|
@ -306,7 +306,7 @@ Use the following example as a guide for specifying roles in *requirements.yml*:
|
|||
scm: hg
|
||||
|
||||
# from GitLab or other git-based scm, using git+ssh
|
||||
- src: git@gitlab.company.com:mygroup/ansible-base.git
|
||||
- src: git@gitlab.company.com:mygroup/ansible-core.git
|
||||
scm: git
|
||||
version: "0.1" # quoted, so YAML doesn't parse this as a floating-point value
|
||||
|
||||
|
|
|
|||
|
|
@ -526,11 +526,11 @@ You can also use "sudo make install".
|
|||
Finding tarballs of tagged releases
|
||||
===================================
|
||||
|
||||
Packaging Ansible or wanting to build a local package yourself, but don't want to do a git checkout? Tarballs of releases are available from ``pypi`` as https://pypi.python.org/packages/source/a/ansible/ansible-{{VERSION}}.tar.gz. You can make VERSION a variable in your package managing system that you update in one place whenever you package a new version. Alternately, you can download https://pypi.python.org/project/ansible to get the latest stable release.
|
||||
If you are packaging Ansible or wanting to build a local package yourself, and you want to avoid a git checkout, you can use a tarball of a tagged release. You can download the latest stable release from PyPI's `ansible package page <https://pypi.org/project/ansible/>`_. If you need a specific older version, beta version, or release candidate, you can use the pattern ``pypi.python.org/packages/source/a/ansible/ansible-{{VERSION}}.tar.gz``. VERSION must be the full version number, for example 3.1.0 or 4.0.0b2. You can make VERSION a variable in your package managing system that you update in one place whenever you package a new version.
|
||||
|
||||
.. note::
|
||||
|
||||
If you are creating your own Ansible package, you must also download or package ``ansible-base`` as part of your Ansible package. You can download it as https://pypi.python.org/packages/source/a/ansible-base/ansible-base-{{VERSION}}.tar.gz.
|
||||
If you are creating your own Ansible package, you must also download or package ``ansible-core`` (or ``ansible-base`` for packages based on 2.10.x) from PyPI as part of your Ansible package. You must specify a particular version. Visit the PyPI project pages to download files for `ansible-core <https://pypi.org/project/ansible-core/>`_ or `ansible-base <https://pypi.org/project/ansible-base/>`_.
|
||||
|
||||
These releases are also tagged in the `git repository <https://github.com/ansible/ansible/releases>`_ with the release version.
|
||||
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ Here are some commonly asked questions and their answers.
|
|||
Where did all the modules go?
|
||||
+++++++++++++++++++++++++++++
|
||||
|
||||
In July, 2019, we announced that collections would be the `future of Ansible content delivery <https://www.ansible.com/blog/the-future-of-ansible-content-delivery>`_. A collection is a distribution format for Ansible content that can include playbooks, roles, modules, and plugins. In Ansible 2.9 we added support for collections. In Ansible 2.10 we `extracted most modules from the main ansible/ansible repository <https://access.redhat.com/solutions/5295121>`_ and placed them in :ref:`collections <list_of_collections>`. Collections may be maintained by the Ansible team, by the Ansible community, or by Ansible partners. The `ansible/ansible repository <https://github.com/ansible/ansible>`_ now contains the code for basic features and functions, such as copying module code to managed nodes. This code is also known as ``ansible-base``.
|
||||
In July, 2019, we announced that collections would be the `future of Ansible content delivery <https://www.ansible.com/blog/the-future-of-ansible-content-delivery>`_. A collection is a distribution format for Ansible content that can include playbooks, roles, modules, and plugins. In Ansible 2.9 we added support for collections. In Ansible 2.10 we `extracted most modules from the main ansible/ansible repository <https://access.redhat.com/solutions/5295121>`_ and placed them in :ref:`collections <list_of_collections>`. Collections may be maintained by the Ansible team, by the Ansible community, or by Ansible partners. The `ansible/ansible repository <https://github.com/ansible/ansible>`_ now contains the code for basic features and functions, such as copying module code to managed nodes. This code is also known as ``ansible-core`` (it was briefly called ``ansible-base`` for version 2.10).
|
||||
|
||||
* To learn more about using collections, see :ref:`collections`.
|
||||
* To learn more about developing collections, see :ref:`developing_collections`.
|
||||
|
|
|
|||
|
|
@ -24,10 +24,13 @@ when a term comes up on the mailing list.
|
|||
lots of other operations together.
|
||||
|
||||
Ansible (the package)
|
||||
A software package (Python, deb, rpm, and so on) that contains ansible-base and a select group of collections. Playbooks that worked with Ansible 2.9 should still work with the Ansible 2.10 package. See the :file:`ansible-<version>.build` file in the release-specific directory at `ansible-build-data <https://github.com/ansible-community/ansible-build-data>`_ for a list of collections included in Ansible, as well as the included ``ansible-base`` version.
|
||||
A software package (Python, deb, rpm, and so on) that contains ansible-core and a select group of collections. Playbooks that worked with Ansible 2.9 should still work with the Ansible 2.10 package. See the :file:`ansible-<version>.build` file in the release-specific directory at `ansible-build-data <https://github.com/ansible-community/ansible-build-data>`_ for a list of collections included in Ansible, as well as the included ``ansible-core`` version.
|
||||
|
||||
ansible-base
|
||||
New for 2.10. The installable package (RPM/Python/Deb package) generated from the `ansible/ansible repository <https://github.com/ansible/ansible>`_. Contains the command-line tools and the code for basic features and functions, such as copying module code to managed nodes. The ``ansible-base`` package includes a few modules and plugins and allows you to add others by installing collections.
|
||||
Used only for 2.10. The installable package (RPM/Python/Deb package) generated from the `ansible/ansible repository <https://github.com/ansible/ansible>`_. See ``ansible-core``.
|
||||
|
||||
ansible-core
|
||||
Name used starting with 2.11. The installable package (RPM/Python/Deb package) generated from the `ansible/ansible repository <https://github.com/ansible/ansible>`_. Contains the command-line tools and the code for basic features and functions, such as copying module code to managed nodes. The ``ansible-core`` package includes a few modules and plugins and allows you to add others by installing collections.
|
||||
|
||||
Ansible Galaxy
|
||||
An `online resource <galaxy.ansible.com>`_ for finding and sharing Ansible community content. Also, the command-line utility that lets users install individual Ansible Collections, for example`` ansible-galaxy install community.crypto``.
|
||||
|
|
@ -59,7 +62,7 @@ when a term comes up on the mailing list.
|
|||
not substitute it for a good staging environment.
|
||||
|
||||
Collection
|
||||
A packaging format for bundling and distributing Ansible content, including plugins, roles, modules, and more. Collections release independent of other collections or ``ansible-base`` so features can be available sooner to users. Some collections are packaged with Ansible (version 2.10 or later). You can install other collections (or other versions of collections) with ``ansible-galaxy collection install <namespace.collection>``.
|
||||
A packaging format for bundling and distributing Ansible content, including plugins, roles, modules, and more. Collections release independent of other collections or ``ansible-core`` so features can be available sooner to users. Some collections are packaged with Ansible (version 2.10 or later). You can install other collections (or other versions of collections) with ``ansible-galaxy collection install <namespace.collection>``.
|
||||
|
||||
Collection name
|
||||
The second part of a Fully Qualified Collection Name. The collection name divides the collection namespace and usually reflects the function of the collection content. For example, the ``cisco`` namespace might contain ``cisco.ios``, ``cisco.aci``, and ``cisco.nxos``, with content for managing the different network devices maintained by Cisco.
|
||||
|
|
|
|||
|
|
@ -118,7 +118,7 @@ devel In development (ansible-core 2.11
|
|||
============================================= ======================================================
|
||||
|
||||
.. _2.10 ansible-base Release Notes:
|
||||
.. _2.10-base: https://github.com/ansible/ansible/blob/stable-2.10/changelogs/CHANGELOG-v2.10.rst
|
||||
.. _2.10: https://github.com/ansible/ansible/blob/stable-2.10/changelogs/CHANGELOG-v2.10.rst
|
||||
.. _2.9 Release Notes:
|
||||
.. _2.9: https://github.com/ansible/ansible/blob/stable-2.9/changelogs/CHANGELOG-v2.9.rst
|
||||
.. _2.8 Release Notes:
|
||||
|
|
|
|||
|
|
@ -32,7 +32,7 @@ Maintenance
|
|||
Issue Reporting
|
||||
===============
|
||||
|
||||
If you find a bug that affects a plugin in the main Ansible repo, also known as ``ansible-base``:
|
||||
If you find a bug that affects a plugin in the main Ansible repo, also known as ``ansible-core``:
|
||||
|
||||
#. Confirm that you are running the latest stable version of Ansible or the devel branch.
|
||||
#. Look at the `issue tracker in the Ansible repo <https://github.com/ansible/ansible/issues>`_ to see if an issue has already been filed.
|
||||
|
|
@ -56,7 +56,7 @@ If you find a bug that affects a module in an Automation Hub collection:
|
|||
Support
|
||||
=======
|
||||
|
||||
All plugins that remain in ``ansible-base`` and all collections hosted in Automation Hub are supported by Red Hat. No other plugins or collections are supported by Red Hat. If you have a subscription to the Red Hat Ansible Automation Platform, you can find more information and resources on the `Red Hat Customer Portal. <https://access.redhat.com/>`_
|
||||
All plugins that remain in ``ansible-core`` and all collections hosted in Automation Hub are supported by Red Hat. No other plugins or collections are supported by Red Hat. If you have a subscription to the Red Hat Ansible Automation Platform, you can find more information and resources on the `Red Hat Customer Portal. <https://access.redhat.com/>`_
|
||||
|
||||
.. seealso::
|
||||
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@
|
|||
Using filters to manipulate data
|
||||
********************************
|
||||
|
||||
Filters let you transform JSON data into YAML data, split a URL to extract the hostname, get the SHA1 hash of a string, add or multiply integers, and much more. You can use the Ansible-specific filters documented here to manipulate your data, or use any of the standard filters shipped with Jinja2 - see the list of :ref:`built-in filters <jinja2:builtin-filters>` in the official Jinja2 template documentation. You can also use :ref:`Python methods <jinja2:python-methods>` to transform data. You can :ref:`create custom Ansible filters as plugins <developing_filter_plugins>`, though we generally welcome new filters into the ansible-base repo so everyone can use them.
|
||||
Filters let you transform JSON data into YAML data, split a URL to extract the hostname, get the SHA1 hash of a string, add or multiply integers, and much more. You can use the Ansible-specific filters documented here to manipulate your data, or use any of the standard filters shipped with Jinja2 - see the list of :ref:`built-in filters <jinja2:builtin-filters>` in the official Jinja2 template documentation. You can also use :ref:`Python methods <jinja2:python-methods>` to transform data. You can :ref:`create custom Ansible filters as plugins <developing_filter_plugins>`, though we generally welcome new filters into the ansible-core repo so everyone can use them.
|
||||
|
||||
Because templating happens on the Ansible controller, **not** on the target host, filters execute on the controller and transform data locally.
|
||||
|
||||
|
|
|
|||
|
|
@ -19,7 +19,7 @@ You can populate variables using lookups. Ansible evaluates the value each time
|
|||
- debug:
|
||||
msg: "motd value is {{ motd_value }}"
|
||||
|
||||
For more details and a list of lookup plugins in ansible-base, see :ref:`plugins_lookup`. You may also find lookup plugins in collections. You can review a list of lookup plugins installed on your control machine with the command ``ansible-doc -l -t lookup``.
|
||||
For more details and a list of lookup plugins in ansible-core, see :ref:`plugins_lookup`. You may also find lookup plugins in collections. You can review a list of lookup plugins installed on your control machine with the command ``ansible-doc -l -t lookup``.
|
||||
|
||||
.. seealso::
|
||||
|
||||
|
|
|
|||
Loading…
Reference in a new issue