Add 2.3.0 entries for module_utils via pluginloader, selectors, and py3 (#21019)

* Add 2.3.0 entries for module_utils via pluginloader, selectors, and py3

* Add roadmap-2.3 updates and an item for roadmap-2.4

CHANGELOG.md

@@ -5,6 +5,11 @@ Ansible Changes By Release
 
 ###Major Changes:
 * 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

docs/docsite/rst/roadmap/ROADMAP_2_3.rst

@@ -26,8 +26,8 @@ Target: February/March 2017
 - **Metadata**
 
   - Add metadata to the modules we ship **(done)**
-  - Write code to use metadata in docs
-  - 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]
   
 - **ansible-ssh**
 

docs/docsite/rst/roadmap/ROADMAP_2_4.rst

@@ -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.
+
 - **Facts Refreshening**
 
   - Make setup.py/facts more pluggable