Updated 2.4 roadmap for final publish (#23049)

* Updated 2.4 roadmap for final publish * Update ROADMAP_2_4.rst * Remove "code refactor and unit tests" This is just technical debt work, and not note-worthy for the roadmap * Update ROADMAP_2_4.rst * Update ROADMAP_2_4.rst
2024-09-14 20:13:21 +02:00 · 2017-03-28 15:53:43 -07:00 · 2017-03-28 15:53:43 -07:00 · 24e7a77a32
commit 24e7a77a32
parent e10adc27cc
1 changed files with 171 additions and 15 deletions
--- a/docs/docsite/rst/roadmap/ROADMAP_2_4.rst
+++ b/docs/docsite/rst/roadmap/ROADMAP_2_4.rst
@ -1,19 +1,26 @@
 ****************************
 Ansible by Red Hat, Core 2.4
 ****************************
-**********************
-Target: June/July 2017
-**********************
+******************************
+Target: Aug/Mid-September 2017
+******************************

-This is meant to be a living document, and is **DRAFT** until
-stated otherwise in the document.
+- **Administrivia and Process**
+  - 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

 - **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.

+- **Python 3 and beyond**
+  - Ansible Core Engine and Core modules will be tested 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
+
 - **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:
+  - Extend the ability of the current config system by adding an ansible-config command and add the following:

    - Dump existing config settings

@ -26,9 +33,19 @@ stated otherwise in the document.

 - **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.
+  - 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.
  - Proposal found in ansible/proposals issue `#41 <https://github.com/ansible/proposals/issues/41>`_.

+- **Facts Refreshening**
+
+  - Configurable list of ‘fact modules’ for ``gather_facts``
+  - Fact gathering policy finer grained
+  - Make ``setup.py``/``facts`` more pluggable
+  - 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>`_.
+  - Proposal found in ansible/proposals issue `#17 <https://github.com/ansible/proposals/issues/17>`_.
+
 - **PluginLoader Refactor**

  - Over the past couple releases we've had some thoughts about how
@ -36,9 +53,9 @@ stated otherwise in the document.

    - 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
+    - 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
+    - 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
@ -49,17 +66,156 @@ stated otherwise in the document.
      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**
+- **Static Loop Keyword**

-  - Make setup.py/facts more pluggable
-  - Fact gathering policy finer grained
-  - Improve testing of setup.py/facts.py
+  - Deprecate (not on standard deprecation cycle) ``with_`` in favor of ``loop:``
+  - This ``loop:`` will take only a list
+  - 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.
+
+- **Vault Extensibility**
+
+  - Support for multiple vault passwords
+
+    - Each decrypted item should know which secret to request
+    - Support requesting credentials (password prompt) as callbacks
+
+  - Ability to open and edit file with encrypted vars deencrypted, and encrypt/format on save
+
+- **Globalize Callbacks**
+
+  - Make send_callback available to other code that cannot use it.
+  - Would allow for ‘full formatting’ of output (see JSON callback)
+  - Fixes static ‘include’ display problem
+
+- **Document Plugins**
+
+  - 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>`_.
+
+- **Group Priorities**
+
+  - 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>`_.
+  - Documentation of group priority variable
+
+- **Runtime Check on Modules for Blacklisting**
+
+  - Filter on things like "supported_by" in module metadata
+  - Provide users with an option of "warning, error or allow/ignore"
+  - Configurable via ansible.cfg and environment variable
+
+- **Disambiguate Includes**
+
+  - Create import_x for ‘static includes’ (import_task, import_play, import_role)
+
+    - Any directives are applied to the ‘imported’ tasks
+
+  - Create include_x for ‘dynamic includes’ (include_task, include_role)
+
+    - Any directives apply to the ‘include’  itself
+
+- **Windows Support**
+
+  - New PS/.NET module API
+  - Windows Nano Server support
+  - Windows module_utils pluginloader
+  - Refactor duplicated module code into new module_utils files
+  - Evaluate #Requires directives (existing and new: PS version, OS version, etc)
+  - Improve module debug support/persistence
+  - Explore official DSC support
+  - Explore module intermediate output
+  - Explore Powershell module unit testing
+  - Explore JEA support (stretch)
+  - Extended become support with network/service/batch logon types
+  - Module updates
+
+    - Split "Windows" category into multiple subs
+    - Domain user/group management modules
+    - win_mapped_drive module
+    - win_hotfix
+    - win_updates rewrite to require become
+    - win_package changes required to deprecate win_msi
+    - win_copy re-write

 - **Cloud Provider Support**

-  - Focus on pull requests for various modules
-  - Triage existing merges
+  - AWS
+
+    - Focus on pull requests for various modules
+    - Triage existing merges for modules
+    - Module work
+
+      - elb-target-groups
+      - alb*
+      - ecs
+      - Data Pipelines
+      - VPN
+      - DirectConnect
+
+  - Azure
+
+    - Expose endpoint overrides
+    - Reformat/document module output to collapse internal API structures and surface important data (eg, public IPs, NICs, data disks)
+    - Add load balancer module
+    - Add Azure Functions module
+
+  - Google Cloud Platform
+
+    - New Module: DataProc
+    - Support for Cross-Region HTTP Load Balancing
+    - New Module: GKE
+
+- **Network Roadmap**
+
+  - Removal of ``*_template`` modules
+  - Session Tracing
+  - Refactor ansible-connection to cli
+  - Module Work
+
+    - Declarative intent modules
+    - OpenVSwitch

 - **Contributor Quality of Life**

+  - All Core and Curated modules will work towards having unit testing.
  - More bot improvements!
+  - Test Infrastructure changes
+
+    - Shippable + Bot Integration
+
+      - Provide verified test results to the bot from Shippable so the bot can comment on PRs with CI failures.
+      - Enable the bot to mark PRs with ``ci_verified`` if all CI failures are verified.
+
+    - Windows Server 2016 Integration Tests
+
+      - Restore Windows Server 2016 integration tests on Shippable.
+
+        - Originally enabled during the 2.3 release cycle, but later disabled due to intermittent WinRM issues.
+        - Depends on resolution of WinRM connection issues.
+
+    - Windows Server Nano Integration Tests
+
+      - Add support to ansible-core-ci for Windows Server 2016 Nano and enable on Shippable.
+      - This will use a subset of the existing Windows integration tests.
+      - Depends on resolution of WinRM connection issues.
+
+    - Windows + Python 3 Tests
+
+      - Run basic Windows tests using Python 3 as the controller.
+      - Depends on resolution of WinRM Python 3 issues.
+
+    - Cloud Integration Tests
+
+      - Run existing cloud integration tests for AWS, Azure and GCP as part of CI.
+      - Tests to be run only on cloud module (and module_utils) PRs and merges for the relevant cloud provider.
+
+    - Test Reliability
+
+      - Further improve test reliability to reduce false positives on Shippable.
+      - This continues work from the 2.3 release cycle.
+
+    - Static Code Analysis
+
+      - Further expand the scope and coverage of static analysis.
+      - This continues work from the 2.3 release cycle.