719b1fecfc
* Added in bullet of Python 2.4+ support discontinuation * Update ROADMAP_2_4.rst * Update ROADMAP_2_4.rst
65 lines
2.7 KiB
ReStructuredText
65 lines
2.7 KiB
ReStructuredText
****************************
|
|
Ansible by Red Hat, Core 2.4
|
|
****************************
|
|
**********************
|
|
Target: June/July 2017
|
|
**********************
|
|
|
|
This is meant to be a living document, and is **DRAFT** until
|
|
stated otherwise in the document.
|
|
|
|
- **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-Config**
|
|
- New yaml format for config
|
|
- Extend the ability of the current config system by adding creating an ansible-config command and add the following:
|
|
|
|
- Dump existing config settings
|
|
|
|
- Update / write a config entry
|
|
|
|
- Show available options (ini entry, yaml, env var, etc)
|
|
|
|
- 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>`_.
|
|
|
|
- **Inventory Overhaul**
|
|
|
|
- Current inventory is overtly 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.
|
|
- Proposal found in ansible/proposals issue `#41 <https://github.com/ansible/proposals/issues/41>`_.
|
|
|
|
- **PluginLoader Refactor**
|
|
|
|
- Over the past couple releases we've had some thoughts about how
|
|
PluginLoader might be better structured
|
|
|
|
- Load the loaders via an initialization function(), not when importing
|
|
the module. (stretch goal, doesn't impact the CLI)
|
|
- Separate duties of PluginLoader from PluginFinder. Most plugins need
|
|
both but Modules and Module_utils only need a PluginFinder
|
|
- Write different PluginFinder subclasses for Module_utils and perhaps
|
|
Modules. Most Plugin types have a flattened namespace and are single
|
|
python files. Modules include code that is not written in python.
|
|
Module_utils are vastly different from the other Plugins as they
|
|
maintain a hierarchical namespace and are multi-file.
|
|
- Potentially split module_utils loader for python from module_utils
|
|
loader for powershell. Currently we only support generic module_utils
|
|
for python modules. The powershell modules always include a single,
|
|
hardcoded powershell module_utils file. If we add generic module_utils
|
|
for powershell, we'll need to decide how to organize the code.
|
|
|
|
- **Facts Refreshening**
|
|
|
|
- Make setup.py/facts more pluggable
|
|
- Fact gathering policy finer grained
|
|
- Improve testing of setup.py/facts.py
|
|
|
|
- **Cloud Provider Support**
|
|
|
|
- Focus on pull requests for various modules
|
|
- Triage existing merges
|
|
|
|
- **Contributor Quality of Life**
|
|
|
|
- More bot improvements!
|