Skip to content

Latest commit

 

History

History
224 lines (155 loc) · 8.3 KB

ROADMAP_2_4.rst

File metadata and controls

224 lines (155 loc) · 8.3 KB

Ansible by Red Hat, Core 2.4

Target: Aug/Mid-September 2017

  • 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 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.
    • Initial PR of code found in ansible/ansible PR #12797.
  • Inventory Overhaul

    • 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.
  • 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.
    • Proposal found in ansible/proposals issue #17.
  • 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.
  • Static Loop Keyword

    • 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.
  • Group Priorities

    • Start using existing group priority variable to sort/merge group vars
    • Implementation for this in ansible/ansible PR #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

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