* Documented and renamed the previously released 'single var vaulting' feature, allowing user to use vault encryption for single variables in a normal YAML vars file.
* Allow module_utils for custom modules to be placed in site-specific
directories and shipped in roles
* On platforms that support it, use more modern system polling API instead of
select in the ssh connection plugin. This removes one limitation on how many
parallel forks are feasible on these systems.
###Minor Changes:
* The version and release facts for OpenBSD hosts were reversed. This has been
@ -20,6 +25,7 @@ Ansible Changes By Release
* default controlpersist path is now a custom hash of host-port-user to avoid the socket path length errors for long hostnames
* Refactored/standardized Windows modules, adding check-mode and diff support where possible
* Extended Windows module API with parameter-type support, helper functions (i.e. Expand-Environment, Warn, Deprecate)
* Various fixes for Python3 compatibility
###Deprecations:
* Specifying --tags (or --skip-tags) multiple times on the command line
- If needed for python2/3 write code to use metadata in module_common or pluginloader
- 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)**
- **Documentation**
@ -83,7 +83,10 @@ Target: February/March 2017
- For 2.3:
- We want all tests to pass (majority do but there’s 10-20 that still need fixes)
- We want all tests to pass
- Just the mercurial tests left because we haven't created an image with
both python2 and python3 to test it on yet.
- 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.
- 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.
@ -135,8 +138,8 @@ Target: February/March 2017
- **Plugin Loader**
- Add module_utils to the plugin loader (feature)
- Split plugin loader: Plugin_search, plugin_loader (modules only use first) (Stretch goal) (slip to 2.4)
- Add module_utils to the plugin loader (feature) [done]
- Split plugin loader: Plugin_search, plugin_loader (modules only use first) [pushed to 2.4]
@ -26,6 +26,26 @@ stated otherwise in the document.
- 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.
Toshio Kuratomi
8 years ago
committed by