* Restructure roadmap so that we can link to sub-parts
So we want to point to specific subsections in the roadmap from the Working Group pages.
This requires the use of subtitles rather than a long list of items and sub-items.
* RST syntax is hard...
* Fixes as requested
* Another fix
* Converted all ROADMAPs to new format
- Figuring out privilege escalation (runas w/ username/password)
- Figuring out privilege escalation (runas w/ username/password)
- Implement kerberos encryption over http
- Implement kerberos encryption over http
- pywinrm conversion to requests (Some mess here on pywinrm/requests. will need docs etc.)
- pywinrm conversion to requests (Some mess here on pywinrm/requests. will need docs etc.)
- NTLM support
- NTLM support
- Modules
- Modules
- Windows
- Finish cleaning up tests and support for post-beta release
- Finish cleaning up tests and support for post-beta release
- Strict mode cleanup (one module in core)
- Strict mode cleanup (one module in core)
- Domain user/group management
- Domain user/group management
- Finish win_host and win_rm in the domain/workgroup modules.
- Finish win_host and win_rm in the domain/workgroup modules.
- Close 2 existing PRs (These were deemed insufficient)
- Close 2 existing PRs (These were deemed insufficient)
- Replicate python module API in PS/C# (deprecate hodgepodge of stuff from module_utils/powershell.ps1)
- Replicate python module API in PS/C# (deprecate hodgepodge of stuff from module_utils/powershell.ps1)
- Network
Network
-------
- Cisco modules (ios, iosxr, nxos, iosxe)
- Cisco modules (ios, iosxr, nxos, iosxe)
- Arista modules (eos)
- Arista modules (eos)
- Juniper modules (junos)
- Juniper modules (junos)
@ -29,11 +36,18 @@ Target: April
- Dell (os10) - At risk
- Dell (os10) - At risk
- Netconf shared module
- Netconf shared module
- Hooks for supporting Tower credentials
- Hooks for supporting Tower credentials
- VMware (This one is a little at risk due to staffing. We're investigating some community maintainers and shifting some people at Ansible around, but it is a VERY high priority).
VMware
------
This one is a little at risk due to staffing. We're investigating some community maintainers and shifting some people at Ansible around, but it is a VERY high priority.
- vsphere\_guest brought to parity with other vmware modules (vs Viasat and 'whereismyjetpack' provided modules)
- vsphere\_guest brought to parity with other vmware modules (vs Viasat and 'whereismyjetpack' provided modules)
- VMware modules moved to official pyvmomi bindings
- VMware modules moved to official pyvmomi bindings
- VMware inventory script updates for pyvmomi, adding tagging support
- VMware inventory script updates for pyvmomi, adding tagging support
- Azure (Notes: This is on hold until Microsoft swaps out the code generator on the Azure Python SDK, which may introduce breaking changes. We have basic modules working against all of these resources at this time. Could ship it against current SDK, but may break. Or should the version be pinned?)
Azure
-----
This is on hold until Microsoft swaps out the code generator on the Azure Python SDK, which may introduce breaking changes. We have basic modules working against all of these resources at this time. Could ship it against current SDK, but may break. Or should the version be pinned?)
- Minimal Azure coverage using new ARM api
- Minimal Azure coverage using new ARM api
- Resource Group
- Resource Group
- Virtual Network
- Virtual Network
@ -44,16 +58,27 @@ Target: April
- Security Group
- Security Group
- Virtual Machine
- Virtual Machine
- Update of inventory script to use new API, adding tagging support
- Update of inventory script to use new API, adding tagging support
- Docker:
Docker
------
- Start Docker module refactor
- Start Docker module refactor
- Update to match current docker CLI capabilities
- Update to match current docker CLI capabilities
- Docker exec support
- Docker exec support
- Upgrade other cloud modules or work with community maintainers to upgrade. (In order)
Cloud
-----
Upgrade other cloud modules or work with community maintainers to upgrade. (In order)
- AWS (Community maintainers)
- AWS (Community maintainers)
- Openstack (Community maintainers)
- Openstack (Community maintainers)
- Google (Google/Community)
- Google (Google/Community)
- Digital Ocean (Community)
- Digital Ocean (Community)
- Ansiballz (renamed from Ziploader):
Ansiballz
---------
Renamed from Ziploader
- Write code to create the zipfile that gets passed across the wire to be run on the remote python
- Write code to create the zipfile that gets passed across the wire to be run on the remote python
- Port most of the functionality in module\_utils to be usage in ansiballz instead
- Port most of the functionality in module\_utils to be usage in ansiballz instead
- Port a few essential modules to use ansiballz instead of module-replacer as proof of concept
- Port a few essential modules to use ansiballz instead of module-replacer as proof of concept
@ -61,11 +86,21 @@ Target: April
- Better testing of modules, caching of modules clientside(Have not yet arrived at an architecture for this that we like), better code sharing between ansible/ansible and modules
- Better testing of modules, caching of modules clientside(Have not yet arrived at an architecture for this that we like), better code sharing between ansible/ansible and modules
- ansiballz is a helpful building block for: python3 porting(high priority), better code sharing between modules(medium priority)
- ansiballz is a helpful building block for: python3 porting(high priority), better code sharing between modules(medium priority)
- ansiballz is a good idea before: enabling users to have custom module_utils directories
- ansiballz is a good idea before: enabling users to have custom module_utils directories
- Expand module diff support (already in progress in devel)
Diff-support
------------
Expand module diff support (already in progress in devel)
- Framework done. Need to add to modules, test etc.
- Framework done. Need to add to modules, test etc.
- Coordinate with community to update their modules
- Coordinate with community to update their modules
- Things being kicking down the road that we said we’d do
Other
-----
Things being kicking down the road that we said we’d do
- NOT remerging core with ansible/ansible this release cycle
- NOT remerging core with ansible/ansible this release cycle
- Community stuff
Community
---------
- Define the process/ETA for reviewing PR’s from community
- Define the process/ETA for reviewing PR’s from community
- Publish better docs and how-tos for submitting code/features/fixes
- Publish better docs and how-tos for submitting code/features/fixes
- Openshift: oso_deployment, oso_route, oso_service, oso_login (...and possibly others. These are modules being developed to support `ansible-container <https://github.com/ansible/ansible-container>`_.): Deferred for later release
- Openshift: oso_deployment, oso_route, oso_service, oso_login (...and possibly others. These are modules being developed to support `ansible-container <https://github.com/ansible/ansible-container>`_.): Deferred for later release
- Kubernetes: kube_deployment, kube_service, kube_login (...and possibly others. These too are modules being developed to support `ansible-container <https://github.com/ansible/ansible-container>`_): Deferred for later release
- Kubernetes: kube_deployment, kube_service, kube_login (...and possibly others. These too are modules being developed to support `ansible-container <https://github.com/ansible/ansible-container>`_): Deferred for later release
- **Extras split from Core** (Team, Community, lead by Jason M and Jimi-c) (Targeting 2.2, could move into 2.3).
Extras split from Core
----------------------
Lead by Jason M and Jimi-c (Targeting 2.2, could move into 2.3).
Targeted towards the 2.2 release or shortly after, we are planning on splitting Extras out of the “Ansible Core” project. That means that modules that are shipped with Ansible by default are **only** the modules in ansibl-modules-core. Ansible extras will become a separate project, managed by the community standard. Over the next few months we’re going to have a lot of work to do on getting all of the modules in the right places for this to work.
Targeted towards the 2.2 release or shortly after, we are planning on splitting Extras out of the “Ansible Core” project. That means that modules that are shipped with Ansible by default are **only** the modules in ansibl-modules-core. Ansible extras will become a separate project, managed by the community standard. Over the next few months we’re going to have a lot of work to do on getting all of the modules in the right places for this to work.
- Create proposal (Jason or Jimi)
- Create proposal (Jason or Jimi)
@ -22,46 +27,63 @@ Target: September 2016
- Library dependencies
- Library dependencies
- Decide and implement release schedules between Ansible Core and Extras to ensure compatibility and longevity for modules and versions of Ansible.
- Decide and implement release schedules between Ansible Core and Extras to ensure compatibility and longevity for modules and versions of Ansible.
- **Tweaks/Fixes**
Tweaks/Fixes
------------
- Connection handling stuff. (Toshio K. and Brian C.): This is a stretch goal for 2.2.**This work got pushed out**
- Connection handling stuff. (Toshio K. and Brian C.): This is a stretch goal for 2.2.**This work got pushed out**
- Change connection polling to avoid resource limitations, see `<https://github.com/ansible/ansible/issues/14143>`_
- Change connection polling to avoid resource limitations, see `<https://github.com/ansible/ansible/issues/14143>`_
- vsphere: feature parity with whereismyjetpack and viasat modules
- vsphere: feature parity with whereismyjetpack and viasat modules
- **Windows platform feature parity** (Matt D)
Windows
-------
Lead by Matt D
- Feature parity
- PS module API (mirror Python module API where appropriate). Note: We don’t necessarily like the current python module API (AnsibleModule is a huge class with many unrelated utility functions. Maybe we should redesign both at the same time?) (bumped to 2.3+ due to "moving target" uncertainty)
- PS module API (mirror Python module API where appropriate). Note: We don’t necessarily like the current python module API (AnsibleModule is a huge class with many unrelated utility functions. Maybe we should redesign both at the same time?) (bumped to 2.3+ due to "moving target" uncertainty)
- Environment keyword support(done)
- Environment keyword support(done)
@ -69,14 +91,16 @@ Target: September 2016
- Async support(done)
- Async support(done)
- (stretch goal) Pipelining(bumped to 2.3+)
- (stretch goal) Pipelining(bumped to 2.3+)
- **Windows-specific enhancements** (Matt D)
- Windows-specific enhancements
- Multiple Kerberos credential support (done)
- Multiple Kerberos credential support (done)
- Server 2016 testing/fixes(done, awaiting next TP/RTM)
- Server 2016 testing/fixes(done, awaiting next TP/RTM)
- (stretch goal) Nano Server connection + module_utils working (bumped to 2.3)
- (stretch goal) Nano Server connection + module_utils working (bumped to 2.3)
- (stretch goal) Encrypted kerberos support in pywinrm(bumped to 2.3)
- (stretch goal) Encrypted kerberos support in pywinrm(bumped to 2.3)
- **Network** (Nate C/Peter S)
Network
-------
Lead by Nate C, Peter S
- **Done:** Unify NetworkModules (module_utils/network.py) as much as possible
- **Done:** Unify NetworkModules (module_utils/network.py) as much as possible
- **Done:** Add support for config diff and replace on supported platforms (2 weeks)
- **Done:** Add support for config diff and replace on supported platforms (2 weeks)
@ -91,11 +115,15 @@ Target: September 2016
- **Deferred:** (stretch goal) Bird modules
- **Deferred:** (stretch goal) Bird modules
- **Deferred:** (stretch goal) GoBGP modules
- **Deferred:** (stretch goal) GoBGP modules
Role revamp
-----------
- **Implement ‘role revamp’ proposal to give users more control on role/task execution (Brian)**
- **Implement ‘role revamp’ proposal to give users more control on role/task execution (Brian)**
- Allow for multiple vault secrets https://github.com/ansible/ansible/issues/13243
- Allow for multiple vault secrets https://github.com/ansible/ansible/issues/13243
- Config option to turn ‘unvaulting’ failures into warnings https://github.com/ansible/ansible/issues/13244
- Config option to turn ‘unvaulting’ failures into warnings https://github.com/ansible/ansible/issues/13244
- **Python3** (Toshio)
Python3
-------
Lead by Toshio
A note here from Jason M: Getting to complete, tested Python 3 is both
A note here from Jason M: Getting to complete, tested Python 3 is both
a critical task and one that has so much work and so many moving parts
a critical task and one that has so much work and so many moving parts
that we don’t expect this to be complete by the 2.2 release. Toshio will
that we don’t expect this to be complete by the 2.2 release. Toshio will
@ -128,6 +159,7 @@ Target: September 2016
passing on Python3. Code has not been line-by-line audited so bugs
passing on Python3. Code has not been line-by-line audited so bugs
remain but can be treated as bugs, not as massive, invasive new features.
remain but can be treated as bugs, not as massive, invasive new features.
- Almost all of our deps have been ported:
- Almost all of our deps have been ported:
- The base deps in setup.py are ported: ['paramiko', 'jinja2', "PyYAML", 'setuptools', 'pycrypto >= 2.6']
- The base deps in setup.py are ported: ['paramiko', 'jinja2', "PyYAML", 'setuptools', 'pycrypto >= 2.6']
- python-six from the rpm spec file has been ported
- python-six from the rpm spec file has been ported
- Python-keyczar from the rpm spec file is not.
- Python-keyczar from the rpm spec file is not.
@ -137,15 +169,19 @@ Target: September 2016
**Mostly done:** Also not line-by-line audited but the unittests
**Mostly done:** Also not line-by-line audited but the unittests
and integration tests do show that the most use functionality is working.
and integration tests do show that the most use functionality is working.
- Add module_utils files to help port
- Add module_utils files to help port
- Update: copy of the six library (v1.4.1 for python2.4 compat) and unicode helpers are here (ansible.module_utils._text.{to_bytes,to_text,to_native})
- Update: copy of the six library (v1.4.1 for python2.4 compat) and unicode helpers are here (ansible.module_utils._text.{to_bytes,to_text,to_native})
- A few basic modules ported to python3
- A few basic modules ported to python3
- Stat module best example module since it’s essential.
- Stat module best example module since it’s essential.
- Update:
- Update:
- A handful of modules like stat have been line-by-line ported. They should work reliably with few python3-specific bugs. All but three integration tests pass which means that most essential modules are working to some extent on Python3.
- A handful of modules like stat have been line-by-line ported. They should work reliably with few python3-specific bugs. All but three integration tests pass which means that most essential modules are working to some extent on Python3.
- The three failing tests are: service, hg, and uri.
- The three failing tests are: service, hg, and uri.
- Note, large swaths of the modules are not tested. The status of
- Note, large swaths of the modules are not tested. The status of
these is unknown
these is unknown
- All code should compile under Python3.
- All code should compile under Python3.
- lib/ansible/* and all modules now compile under Python-3.5
- lib/ansible/* and all modules now compile under Python-3.5
@ -155,13 +191,17 @@ Target: September 2016
- More integration tests. Currently integration tests are the best way to test ansible modules so we have to rely on those.
- More integration tests. Currently integration tests are the best way to test ansible modules so we have to rely on those.
- Goals for 2.3:
- Goals for 2.3:
- Bugfixing, bugfixing, bugfixing. We need community members to test,
- Bugfixing, bugfixing, bugfixing. We need community members to test,
submit bugs, and add new unit and integration tests. I'll have some
submit bugs, and add new unit and integration tests. I'll have some
time allocated both to review any Python3 bugfixes that they submit
time allocated both to review any Python3 bugfixes that they submit
and to work on bug reports without PRs. The overall goal is to make
and to work on bug reports without PRs. The overall goal is to make
the things that people do in production with Ansible work on Python 3.
the things that people do in production with Ansible work on Python 3.
- **Infrastructure Buildout and Changes** (Matt Clay)
Infrastructure Buildout and Changes
-----------------------------------
Lead by Matt Clay
Another note from Jason M: A lot of this work is to ease the burden of CI, CI performance, increase our testing coverage and all of that sort of thing. It’s not necessarily feature work, but it’s \*\*critical\*\* to growing our product and our ability to get community changes in more securely and quickly.
Another note from Jason M: A lot of this work is to ease the burden of CI, CI performance, increase our testing coverage and all of that sort of thing. It’s not necessarily feature work, but it’s \*\*critical\*\* to growing our product and our ability to get community changes in more securely and quickly.
- The 2.3 Ansible Core is just a little different than the past two major releases we've done. In addition to feature work, we're using part of the time for this release to reduce some of our backlog in other areas than pure development.
- The 2.3 Ansible Core is just a little different than the past two major releases we've done. In addition to feature work, we're using part of the time for this release to reduce some of our backlog in other areas than pure development.
- *Administration:* Clean up our GitHub repos and move to one repo so that contributions, tickets, submissions, etc are centralized and easier for both the community and the Core Team to manage.
- *Administration:* Clean up our GitHub repos and move to one repo so that contributions, tickets, submissions, etc are centralized and easier for both the community and the Core Team to manage.
@ -15,28 +14,31 @@ Target: Mid April 2017
- *Python 3:* The community and Toshio have done TONS of work getting Python 3 working. Still more to go...
- *Python 3:* The community and Toshio have done TONS of work getting Python 3 working. Still more to go...
- *Features:* We still have some cool stuff coming. Check it out below. For people on the Networking side of the world, the Persistent Connection Manager will be a *huge* feature and performance gain.
- *Features:* We still have some cool stuff coming. Check it out below. For people on the Networking side of the world, the Persistent Connection Manager will be a *huge* feature and performance gain.
Repo Merge
- **Repo Merge**
----------
- Script that a submitter can run to migrate their PR **(done)**
- Script that a submitter can run to migrate their PR **(done)**
- Script that a committer can run to fork a PR and then merge to ansible/ansible **(mostly done)**
- Script that a committer can run to fork a PR and then merge to ansible/ansible **(mostly done)**
- Move all the issues (remove old ones that can be removed) **(done)**
- Move all the issues (remove old ones that can be removed) **(done)**
- Enhance ansibullbot to accommodate the changes (jctanner) **(in progress, going well)**
- Enhance ansibullbot to accommodate the changes (jctanner) **(in progress, going well)**
- **Metadata**
Metadata
--------
- Add metadata to the modules we ship **(done)**
- Add metadata to the modules we ship **(done)**
- Write code to use metadata in docs **(done)**
- Write code to use metadata in docs **(done)**
- If needed for python2/3 write code to use metadata in module_common or pluginloader **(not needed)**
- If needed for python2/3 write code to use metadata in module_common or pluginloader **(not needed)**
- **Documentation**
Documentation
-------------
- Update developing_modules **(in progress, will continue in 2.4)**
- Update developing_modules **(in progress, will continue in 2.4)**
- Set up rst skeleton for module_utils docs.
- Set up rst skeleton for module_utils docs.
- Plugin development docs
- Plugin development docs
- Speed up `make webdocs` https://github.com/ansible/ansible/issues/17406 **(done)**
- Speed up `make webdocs` https://github.com/ansible/ansible/issues/17406 **(done)**
- **Windows platform** (nitzmahone)
Windows
-------
Lead by nitzmahone
- **Platform**
- Pipelining support **(done)**
- Pipelining support **(done)**
- Become support **(done/experimental)**
- Become support **(done/experimental)**
@ -48,7 +50,7 @@ Target: Mid April 2017
- Kerberos encryption (via notting, pywinrm/requests_kerberos/pykerberos) **(in progress, available in pywinrm post 2.3 release)**
- Kerberos encryption (via notting, pywinrm/requests_kerberos/pykerberos) **(in progress, available in pywinrm post 2.3 release)**
- Fix plugin-specific connection var lookup/delegation (either registered explicitly by plugins or ansible_(plugin)_*) **(bumped to 2.4)**
- Fix plugin-specific connection var lookup/delegation (either registered explicitly by plugins or ansible_(plugin)_*) **(bumped to 2.4)**
- **Windows modules** (nitzmahone)
- **Modules**
- win_domain module **(done)**
- win_domain module **(done)**
- win_domain_membership module **(done)**
- win_domain_membership module **(done)**
@ -61,7 +63,9 @@ Target: Mid April 2017
- Updates to win_updates, adopt to core (stretch) **(bump to 2.4)**
- Updates to win_updates, adopt to core (stretch) **(bump to 2.4)**
- Updates to win_package, adopt to core (+ deprecate win_msi) (stretch) **(bump to 2.4)**
- Updates to win_package, adopt to core (+ deprecate win_msi) (stretch) **(bump to 2.4)**
- **Azure modules** (nitzmahone/mattclay)
Azure
-----
Lead by nitzmahone, mattclay
- Ensure Azure SDK rc6/RTM work **(done)**
- Ensure Azure SDK rc6/RTM work **(done)**
- Move tests from ansible/azure_rm repo to ansible/ansible **(bump to 2.4, no CI resources)**
- Move tests from ansible/azure_rm repo to ansible/ansible **(bump to 2.4, no CI resources)**
@ -70,8 +74,8 @@ Target: Mid April 2017
- Get Azure tests running in CI (stretch, depends on availability of sponsored account) **(bump to 2.4, no CI resources)**
- Get Azure tests running in CI (stretch, depends on availability of sponsored account) **(bump to 2.4, no CI resources)**
- azure_rm_loadbalancer module (stretch) **(bump to 2.4)**
- azure_rm_loadbalancer module (stretch) **(bump to 2.4)**
- Just the mercurial tests left because we haven't created an image with
- Just the mercurial tests left because we haven't created an image with
both python2 and python3 to test it on yet.
both python2 and python3 to test it on yet.
- Check by doing ``grep skip/python3 test/integration/targets/*/aliases``
- Check by doing ``grep skip/python3 test/integration/targets/*/aliases``
- If users report bugs on python3, these should be fixed and will prioritize our work on porting other modules.
- If users report bugs on python3, these should be fixed and will prioritize our work on porting other modules.
- Still have to solve the python3-only and python2-only modules. Thinking of doing this via metadata. Will mean we have to use metadata at the module_common level. Will also mean we don’t support py2-only or py3-only old style python modules.
- Still have to solve the python3-only and python2-only modules. Thinking of doing this via metadata. Will mean we have to use metadata at the module_common level. Will also mean we don’t support py2-only or py3-only old style python modules.
- Note: Most of the currently tested ansible features now run. But there’s still a lot of code that’s untested.
- Note: Most of the currently tested ansible features now run. But there’s still a lot of code that’s untested.
- **Testing and CI** (mattclay)
Testing and CI
--------------
Lead by mattclay
- *Static Code Analysis:* Create custom pylint extensions to automate detection of common Ansible specific issues reported during code review. Automate feedback on PRs for new code only to avoid noise from existing code which does not pass.
- *Static Code Analysis:* Create custom pylint extensions to automate detection of common Ansible specific issues reported during code review. Automate feedback on PRs for new code only to avoid noise from existing code which does not pass.
@ -129,7 +138,9 @@ Target: Mid April 2017
Tests executed on merges are based on changes since the last successful merge test.
Tests executed on merges are based on changes since the last successful merge test.
- **Amazon resources** (ryansb)
Amazon
------
Lead by ryansb
- Improve ec2.py integration tests **(partial, more to do in 2.4)**
- Improve ec2.py integration tests **(partial, more to do in 2.4)**
- ELB version 2 **(pushed - needs_revision [PR](https://github.com/ansible/ansible/pull/19491))**
- ELB version 2 **(pushed - needs_revision [PR](https://github.com/ansible/ansible/pull/19491))**
- Starting with 2.4, all items that are deprecated will be removed in 4 major releases unless otherwise stated.
- Starting with 2.4, all items that are deprecated will be removed in 4 major releases unless otherwise stated.
- For example: A module that is deprecated in 2.4 will be removed in 2.8
- For example: A module that is deprecated in 2.4 will be removed in 2.8
- **Python 2.4 and 2.5 support discontinuation**
Python 2.4 and 2.5 support discontinuation
------------------------------------------
- Ansible will not support Python 2.4 nor 2.5 on the target hosts anymore. Going forward, Python 2.6+ will be required on targets, as already is the case on the controller.
- Ansible will not support Python 2.4 nor 2.5 on the target hosts anymore.
Going forward, Python 2.6+ will be required on targets, as already is the case on the controller.
- **Python 3 and beyond**
Python 3
--------
- Ansible Core Engine and Core modules will be tested on Python 3
- Ansible Core Engine and Core modules will be tested on Python 3
- Communicate with Linux distros to provide Ansible running on Python 3
- Communicate with Linux distros to provide Ansible running on Python 3
- Check for Python 3 tests on core modules and create any missing
- Check for Python 3 tests on core modules and create any missing
- **Ansible-Config**
Ansible-Config
--------------
- New yaml format for config
- New yaml format for config
- Extend the ability of the current config system by adding an ansible-config command and add the following:
- Extend the ability of the current config system by adding an ``ansible-config`` command and add the following:
- Dump existing config settings
- Dump existing config settings
- Update / write a config entry
- Update / write a config entry
- Show available options (ini entry, yaml, env var, etc)
- Show available options (ini entry, yaml, env var, etc)
- Proposal found in ansible/proposals issue `#35 <https://github.com/ansible/proposals/issues/35>`_.
- Proposal found in ansible/proposals issue `#35 <https://github.com/ansible/proposals/issues/35>`_.
- Initial PR of code found in ansible/ansible PR `#12797 <https://github.com/ansible/ansible/pull/12797>`_.
- Initial PR of code found in ansible/ansible PR `#12797 <https://github.com/ansible/ansible/pull/12797>`_.
- **Inventory Overhaul**
Inventory
---------
- Current inventory is overly complex, non modular and mostly still a legacy from inception.
- Current inventory is overly complex, non modular and mostly still a legacy from inception.
- We also want to add a common set of features to most inventory sources but are hampered by the current code base.
- We also want to add a common set of features to most inventory sources but are hampered by the current code base.
- Proposal found in ansible/proposals issue `#41 <https://github.com/ansible/proposals/issues/41>`_.
- Proposal found in ansible/proposals issue `#41 <https://github.com/ansible/proposals/issues/41>`_.
- **Facts Refreshening**
Facts
-----
- Configurable list of ‘fact modules’ for ``gather_facts``
- Configurable list of ‘fact modules’ for ``gather_facts``
- Fact gathering policy finer grained
- Fact gathering policy finer grained
- Make ``setup.py``/``facts`` more pluggable
- Make ``setup.py``/``facts`` more pluggable
- Improve testing of ``setup.py``/``facts.py``
- Improve testing of ``setup.py``/``facts.py``
- Namespacing fact variables (via a config option) implemented in ansible/ansible PR `#18445 <https://github.com/ansible/ansible/pull/18445>`_.
- Namespacing fact variables (via a config option) implemented in ansible/ansible PR `#18445 <https://github.com/ansible/ansible/pull/18445>`_.
- Proposal found in ansible/proposals issue `#17 <https://github.com/ansible/proposals/issues/17>`_.
Proposal found in ansible/proposals issue `#17 <https://github.com/ansible/proposals/issues/17>`_.
- **PluginLoader Refactor**
PluginLoader
------------
- Over the past couple releases we've had some thoughts about how
- Over the past couple releases we've had some thoughts about how
PluginLoader might be better structured
PluginLoader might be better structured
@ -69,15 +69,15 @@ Target: Aug/Mid-September 2017
hardcoded powershell module_utils file. If we add generic module_utils
hardcoded powershell module_utils file. If we add generic module_utils
for powershell, we'll need to decide how to organize the code.
for powershell, we'll need to decide how to organize the code.
- **Static Loop Keyword**
Static Loop Keyword
-------------------
- Deprecate (not on standard deprecation cycle) ``with_`` in favor of ``loop:``
- Deprecate (not on standard deprecation cycle) ``with_`` in favor of ``loop:``
- This ``loop:`` will take only a list
- This ``loop:`` will take only a list
- Remove complexity from loops, lookups are still available to users
- Remove complexity from loops, lookups are still available to users
- Less confusing having a static directive vs a one that is dynamic depending on plugins loaded.
- Less confusing having a static directive vs a one that is dynamic depending on plugins loaded.
- **Vault Extensibility**
Vault
-----
- Support for multiple vault passwords
- Support for multiple vault passwords
- Each decrypted item should know which secret to request
- Each decrypted item should know which secret to request
@ -85,31 +85,31 @@ Target: Aug/Mid-September 2017
- Ability to open and edit file with encrypted vars deencrypted, and encrypt/format on save
- Ability to open and edit file with encrypted vars deencrypted, and encrypt/format on save
- **Globalize Callbacks**
Globalize Callbacks
-------------------
- Make send_callback available to other code that cannot use it.
- Make send_callback available to other code that cannot use it.
- Would allow for ‘full formatting’ of output (see JSON callback)
- Would allow for ‘full formatting’ of output (see JSON callback)
- Fixes static ‘include’ display problem
- Fixes static ‘include’ display problem
- **Document Plugins**
Plugins
-------
- Allow plugins to have embedded docs (like modules)
- Allow plugins to have embedded docs (like modules)
- Update ansible-doc and website to generate docs from these ansible/ansible PR `#22796 <https://github.com/ansible/ansible/pull/22796>`_.
- Update ansible-doc and website to generate docs from these ansible/ansible PR `#22796 <https://github.com/ansible/ansible/pull/22796>`_.
- **Group Priorities**
Group Priorities
----------------
- Start using existing group priority variable to sort/merge group vars
- Start using existing group priority variable to sort/merge group vars
- Implementation for this in ansible/ansible PR `#22580 <https://github.com/ansible/ansible/pull/22580>`_.
- Implementation for this in ansible/ansible PR `#22580 <https://github.com/ansible/ansible/pull/22580>`_.
- Documentation of group priority variable
- Documentation of group priority variable
- **Runtime Check on Modules for Blacklisting**
Runtime Check on Modules for Blacklisting
-----------------------------------------
- Filter on things like "supported_by" in module metadata
- Filter on things like "supported_by" in module metadata
- Provide users with an option of "warning, error or allow/ignore"
- Provide users with an option of "warning, error or allow/ignore"
- Configurable via ansible.cfg and environment variable
- Configurable via ansible.cfg and environment variable
- **Disambiguate Includes**
Disambiguate Includes
---------------------
- Create import_x for ‘static includes’ (import_task, import_play, import_role)
- Create import_x for ‘static includes’ (import_task, import_play, import_role)
- Any directives are applied to the ‘imported’ tasks
- Any directives are applied to the ‘imported’ tasks
Dag Wieers
7 years ago
committed by