Restructure roadmap so that we can link to sub-parts (#26637)
* Restructure roadmap so that we can link to sub-parts So we want to point to specific subsections in the roadmap from the Working Group pages. This requires the use of subtitles rather than a long list of items and sub-items. * RST syntax is hard... * Fixes as requested * Another fix * Converted all ROADMAPs to new format
This commit is contained in:
Dag Wieers
John R Barker
parent
661b2c5beb
commit
292f109ad6
4 changed files with 553 additions and 469 deletions
|
|
@ -1,71 +1,106 @@
|
|||
****************
|
||||
================
|
||||
Ansible Core 2.1
|
||||
****************
|
||||
*************
|
||||
Target: April
|
||||
*************
|
||||
================
|
||||
**Target: April**
|
||||
|
||||
- Windows, General
|
||||
- Figuring out privilege escalation (runas w/ username/password)
|
||||
- Implement kerberos encryption over http
|
||||
- pywinrm conversion to requests (Some mess here on pywinrm/requests. will need docs etc.)
|
||||
- NTLM support
|
||||
.. contents:: Topics
|
||||
|
||||
|
||||
Windows
|
||||
-------
|
||||
- General
|
||||
|
||||
- Figuring out privilege escalation (runas w/ username/password)
|
||||
- Implement kerberos encryption over http
|
||||
- pywinrm conversion to requests (Some mess here on pywinrm/requests. will need docs etc.)
|
||||
- NTLM support
|
||||
|
||||
- Modules
|
||||
- Windows
|
||||
- Finish cleaning up tests and support for post-beta release
|
||||
- Strict mode cleanup (one module in core)
|
||||
- Domain user/group management
|
||||
- Finish win_host and win_rm in the domain/workgroup modules.
|
||||
- Close 2 existing PRs (These were deemed insufficient)
|
||||
- Replicate python module API in PS/C# (deprecate hodgepodge of stuff from module_utils/powershell.ps1)
|
||||
|
||||
- Network
|
||||
- Cisco modules (ios, iosxr, nxos, iosxe)
|
||||
- Arista modules (eos)
|
||||
- Juniper modules (junos)
|
||||
- OpenSwitch
|
||||
- Cumulus
|
||||
- Dell (os10) - At risk
|
||||
- Netconf shared module
|
||||
- Hooks for supporting Tower credentials
|
||||
- VMware (This one is a little at risk due to staffing. We're investigating some community maintainers and shifting some people at Ansible around, but it is a VERY high priority).
|
||||
- vsphere\_guest brought to parity with other vmware modules (vs Viasat and 'whereismyjetpack' provided modules)
|
||||
- VMware modules moved to official pyvmomi bindings
|
||||
- VMware inventory script updates for pyvmomi, adding tagging support
|
||||
- Azure (Notes: This is on hold until Microsoft swaps out the code generator on the Azure Python SDK, which may introduce breaking changes. We have basic modules working against all of these resources at this time. Could ship it against current SDK, but may break. Or should the version be pinned?)
|
||||
- Minimal Azure coverage using new ARM api
|
||||
- Resource Group
|
||||
- Virtual Network
|
||||
- Subnet
|
||||
- Public IP
|
||||
- Network Interface
|
||||
- Storage Account
|
||||
- Security Group
|
||||
- Virtual Machine
|
||||
- Update of inventory script to use new API, adding tagging support
|
||||
- Docker:
|
||||
- Start Docker module refactor
|
||||
- Update to match current docker CLI capabilities
|
||||
- Docker exec support
|
||||
- Upgrade other cloud modules or work with community maintainers to upgrade. (In order)
|
||||
- AWS (Community maintainers)
|
||||
- Openstack (Community maintainers)
|
||||
- Google (Google/Community)
|
||||
- Digital Ocean (Community)
|
||||
- Ansiballz (renamed from Ziploader):
|
||||
- Write code to create the zipfile that gets passed across the wire to be run on the remote python
|
||||
- Port most of the functionality in module\_utils to be usage in ansiballz instead
|
||||
- Port a few essential modules to use ansiballz instead of module-replacer as proof of concept
|
||||
- New modules will be able to use ansiballz. Old modules will need to be ported in future releases (Some modules will not need porting but others will)
|
||||
- Better testing of modules, caching of modules clientside(Have not yet arrived at an architecture for this that we like), better code sharing between ansible/ansible and modules
|
||||
- ansiballz is a helpful building block for: python3 porting(high priority), better code sharing between modules(medium priority)
|
||||
- ansiballz is a good idea before: enabling users to have custom module_utils directories
|
||||
- Expand module diff support (already in progress in devel)
|
||||
- Framework done. Need to add to modules, test etc.
|
||||
- Coordinate with community to update their modules
|
||||
- Things being kicking down the road that we said we’d do
|
||||
- NOT remerging core with ansible/ansible this release cycle
|
||||
- Community stuff
|
||||
- Define the process/ETA for reviewing PR’s from community
|
||||
- Publish better docs and how-tos for submitting code/features/fixes
|
||||
- Finish cleaning up tests and support for post-beta release
|
||||
- Strict mode cleanup (one module in core)
|
||||
- Domain user/group management
|
||||
- Finish win_host and win_rm in the domain/workgroup modules.
|
||||
|
||||
- Close 2 existing PRs (These were deemed insufficient)
|
||||
|
||||
- Replicate python module API in PS/C# (deprecate hodgepodge of stuff from module_utils/powershell.ps1)
|
||||
|
||||
Network
|
||||
-------
|
||||
- Cisco modules (ios, iosxr, nxos, iosxe)
|
||||
- Arista modules (eos)
|
||||
- Juniper modules (junos)
|
||||
- OpenSwitch
|
||||
- Cumulus
|
||||
- Dell (os10) - At risk
|
||||
- Netconf shared module
|
||||
- Hooks for supporting Tower credentials
|
||||
|
||||
VMware
|
||||
------
|
||||
This one is a little at risk due to staffing. We're investigating some community maintainers and shifting some people at Ansible around, but it is a VERY high priority.
|
||||
|
||||
- vsphere\_guest brought to parity with other vmware modules (vs Viasat and 'whereismyjetpack' provided modules)
|
||||
- VMware modules moved to official pyvmomi bindings
|
||||
- VMware inventory script updates for pyvmomi, adding tagging support
|
||||
|
||||
Azure
|
||||
-----
|
||||
This is on hold until Microsoft swaps out the code generator on the Azure Python SDK, which may introduce breaking changes. We have basic modules working against all of these resources at this time. Could ship it against current SDK, but may break. Or should the version be pinned?)
|
||||
- Minimal Azure coverage using new ARM api
|
||||
- Resource Group
|
||||
- Virtual Network
|
||||
- Subnet
|
||||
- Public IP
|
||||
- Network Interface
|
||||
- Storage Account
|
||||
- Security Group
|
||||
- Virtual Machine
|
||||
- Update of inventory script to use new API, adding tagging support
|
||||
|
||||
|
||||
Docker
|
||||
------
|
||||
- Start Docker module refactor
|
||||
- Update to match current docker CLI capabilities
|
||||
- Docker exec support
|
||||
|
||||
Cloud
|
||||
-----
|
||||
Upgrade other cloud modules or work with community maintainers to upgrade. (In order)
|
||||
|
||||
- AWS (Community maintainers)
|
||||
- Openstack (Community maintainers)
|
||||
- Google (Google/Community)
|
||||
- Digital Ocean (Community)
|
||||
|
||||
Ansiballz
|
||||
---------
|
||||
Renamed from Ziploader
|
||||
|
||||
- Write code to create the zipfile that gets passed across the wire to be run on the remote python
|
||||
- Port most of the functionality in module\_utils to be usage in ansiballz instead
|
||||
- Port a few essential modules to use ansiballz instead of module-replacer as proof of concept
|
||||
- New modules will be able to use ansiballz. Old modules will need to be ported in future releases (Some modules will not need porting but others will)
|
||||
- Better testing of modules, caching of modules clientside(Have not yet arrived at an architecture for this that we like), better code sharing between ansible/ansible and modules
|
||||
- ansiballz is a helpful building block for: python3 porting(high priority), better code sharing between modules(medium priority)
|
||||
- ansiballz is a good idea before: enabling users to have custom module_utils directories
|
||||
|
||||
Diff-support
|
||||
------------
|
||||
Expand module diff support (already in progress in devel)
|
||||
|
||||
- Framework done. Need to add to modules, test etc.
|
||||
- Coordinate with community to update their modules
|
||||
|
||||
Other
|
||||
-----
|
||||
Things being kicking down the road that we said we’d do
|
||||
|
||||
- NOT remerging core with ansible/ansible this release cycle
|
||||
|
||||
Community
|
||||
---------
|
||||
- Define the process/ETA for reviewing PR’s from community
|
||||
- Publish better docs and how-tos for submitting code/features/fixes
|
||||
|
|
|
|||
|
|
@ -1,67 +1,89 @@
|
|||
****************
|
||||
================
|
||||
Ansible Core 2.2
|
||||
****************
|
||||
**********************
|
||||
Target: September 2016
|
||||
**********************
|
||||
================
|
||||
**Target: September 2016**
|
||||
|
||||
- **Docker** (lead by Chris Houseknecht)
|
||||
.. contents:: Topics
|
||||
|
||||
- Docker_network: **done**
|
||||
- Docker_volume: Not in this release
|
||||
- Docker_file: Not in this release.
|
||||
- Openshift: oso_deployment, oso_route, oso_service, oso_login (...and possibly others. These are modules being developed to support `ansible-container <https://github.com/ansible/ansible-container>`_.): Deferred for later release
|
||||
- Kubernetes: kube_deployment, kube_service, kube_login (...and possibly others. These too are modules being developed to support `ansible-container <https://github.com/ansible/ansible-container>`_): Deferred for later release
|
||||
Docker
|
||||
------
|
||||
Lead by Chris Houseknecht
|
||||
|
||||
- **Extras split from Core** (Team, Community, lead by Jason M and Jimi-c) (Targeting 2.2, could move into 2.3).
|
||||
Targeted towards the 2.2 release or shortly after, we are planning on splitting Extras out of the “Ansible Core” project. That means that modules that are shipped with Ansible by default are **only** the modules in ansibl-modules-core. Ansible extras will become a separate project, managed by the community standard. Over the next few months we’re going to have a lot of work to do on getting all of the modules in the right places for this to work.
|
||||
- Docker_network: **done**
|
||||
- Docker_volume: Not in this release
|
||||
- Docker_file: Not in this release.
|
||||
- Openshift: oso_deployment, oso_route, oso_service, oso_login (...and possibly others. These are modules being developed to support `ansible-container <https://github.com/ansible/ansible-container>`_.): Deferred for later release
|
||||
- Kubernetes: kube_deployment, kube_service, kube_login (...and possibly others. These too are modules being developed to support `ansible-container <https://github.com/ansible/ansible-container>`_): Deferred for later release
|
||||
|
||||
- Create proposal (Jason or Jimi)
|
||||
- Review modules for correct location (extras v core)
|
||||
- Extras is a completely different package (does not install with ansible)
|
||||
- Library dependencies
|
||||
- Decide and implement release schedules between Ansible Core and Extras to ensure compatibility and longevity for modules and versions of Ansible.
|
||||
Extras split from Core
|
||||
----------------------
|
||||
Lead by Jason M and Jimi-c (Targeting 2.2, could move into 2.3).
|
||||
|
||||
- **Tweaks/Fixes**
|
||||
Targeted towards the 2.2 release or shortly after, we are planning on splitting Extras out of the “Ansible Core” project. That means that modules that are shipped with Ansible by default are **only** the modules in ansibl-modules-core. Ansible extras will become a separate project, managed by the community standard. Over the next few months we’re going to have a lot of work to do on getting all of the modules in the right places for this to work.
|
||||
|
||||
- Connection handling stuff. (Toshio K. and Brian C.): This is a stretch goal for 2.2. **This work got pushed out**
|
||||
- Create proposal (Jason or Jimi)
|
||||
- Review modules for correct location (extras v core)
|
||||
- Extras is a completely different package (does not install with ansible)
|
||||
- Library dependencies
|
||||
- Decide and implement release schedules between Ansible Core and Extras to ensure compatibility and longevity for modules and versions of Ansible.
|
||||
|
||||
- Change connection polling to avoid resource limitations, see `<https://github.com/ansible/ansible/issues/14143>`_
|
||||
- `<https://docs.python.org/3/library/selectors.html#module-selectors>`_
|
||||
- Code: https://github.com/kai11/ansible/blob/fix/select_fd_out_of_range_wip/lib/ansible/plugins/connection/ssh.py
|
||||
Tweaks/Fixes
|
||||
------------
|
||||
- Connection handling stuff. (Toshio K. and Brian C.): This is a stretch goal for 2.2. **This work got pushed out**
|
||||
|
||||
- **Cloud Modules** (Ryan Brown)
|
||||
- Change connection polling to avoid resource limitations, see `<https://github.com/ansible/ansible/issues/14143>`_
|
||||
- `<https://docs.python.org/3/library/selectors.html#module-selectors>`_
|
||||
- Code: https://github.com/kai11/ansible/blob/fix/select_fd_out_of_range_wip/lib/ansible/plugins/connection/ssh.py
|
||||
|
||||
- AWS
|
||||
|
||||
- Pagination for all AWS modules (generic pagination exists, but isn’t used everywhere) (bumped to 2.3)
|
||||
- Refactoring ec2.py to be more digestible (bumped to 2.3)
|
||||
- Fix inconsistencies with different authentication methods (STS, environment creds, ~/.aws/credentials) (done)
|
||||
- AWS Lambda modules (lambda_execute done, others pending)
|
||||
- Ryan Brown and Robyn Bergeron work on bug/PR triage to reduce backlog (reduced - continuing to work on it)
|
||||
- Google (Ryan Brown and Tom Melendez)
|
||||
AWS
|
||||
---
|
||||
Lead by Ryan Brown
|
||||
|
||||
- Add support for Google Cloud DNS
|
||||
- Add support for Google Cloud managed instance groups (done)
|
||||
- Support restoring instances from snapshots
|
||||
- Improved handling of scratch disks on instances (done)
|
||||
- External OpenStack (Stretch goal for this release)
|
||||
- Pagination for all AWS modules (generic pagination exists, but isn’t used everywhere) (bumped to 2.3)
|
||||
- Refactoring ec2.py to be more digestible (bumped to 2.3)
|
||||
- Fix inconsistencies with different authentication methods (STS, environment creds, ~/.aws/credentials) (done)
|
||||
- AWS Lambda modules (lambda_execute done, others pending)
|
||||
- Ryan Brown and Robyn Bergeron work on bug/PR triage to reduce backlog (reduced - continuing to work on it)
|
||||
|
||||
- Ryan with some help from David Shrewsbury (Zuul/Openstack at RedHat).
|
||||
- Support Heat stack resources (done)
|
||||
- Support LBaaS load balancers
|
||||
- Azure load balancer: Feature parity for AWS ELB (Stretch Goal)
|
||||
Google
|
||||
------
|
||||
Lead by Ryan Brown and Tom Melendez
|
||||
|
||||
- **VMware** (Brian, Jtanner)
|
||||
- Add support for Google Cloud DNS
|
||||
- Add support for Google Cloud managed instance groups (done)
|
||||
- Support restoring instances from snapshots
|
||||
- Improved handling of scratch disks on instances (done)
|
||||
|
||||
- *module/inventory script: port to pyvmomi (jtanner, bcoca)*
|
||||
**done:** https://github.com/ansible/ansible/pull/15967
|
||||
- *inventory script: allow filtering ala ec2 (jtanner) (undergoing PR process)*
|
||||
**done:** https://github.com/ansible/ansible/pull/15967
|
||||
OpenStack
|
||||
---------
|
||||
Lead by Ryan Brown
|
||||
|
||||
- vsphere: feature parity with whereismyjetpack and viasat modules
|
||||
Stretch goal for this release
|
||||
|
||||
- **Windows platform feature parity** (Matt D)
|
||||
- Ryan with some help from David Shrewsbury (Zuul/Openstack at RedHat).
|
||||
- Support Heat stack resources (done)
|
||||
- Support LBaaS load balancers
|
||||
|
||||
Azure load balancer
|
||||
-------------------
|
||||
- Feature parity for AWS ELB (Stretch Goal)
|
||||
|
||||
VMware
|
||||
------
|
||||
Lead by Brian, Jtanner
|
||||
|
||||
- *module/inventory script: port to pyvmomi (jtanner, bcoca)*
|
||||
**done:** https://github.com/ansible/ansible/pull/15967
|
||||
- *inventory script: allow filtering ala ec2 (jtanner) (undergoing PR process)*
|
||||
**done:** https://github.com/ansible/ansible/pull/15967
|
||||
- vsphere: feature parity with whereismyjetpack and viasat modules
|
||||
|
||||
Windows
|
||||
-------
|
||||
Lead by Matt D
|
||||
|
||||
- Feature parity
|
||||
|
||||
- PS module API (mirror Python module API where appropriate). Note: We don’t necessarily like the current python module API (AnsibleModule is a huge class with many unrelated utility functions. Maybe we should redesign both at the same time?) (bumped to 2.3+ due to "moving target" uncertainty)
|
||||
- Environment keyword support (done)
|
||||
|
|
@ -69,131 +91,149 @@ Target: September 2016
|
|||
- Async support (done)
|
||||
- (stretch goal) Pipelining (bumped to 2.3+)
|
||||
|
||||
- **Windows-specific enhancements** (Matt D)
|
||||
- Windows-specific enhancements
|
||||
|
||||
- Multiple Kerberos credential support (done)
|
||||
- Server 2016 testing/fixes (done, awaiting next TP/RTM)
|
||||
- (stretch goal) Nano Server connection + module_utils working (bumped to 2.3)
|
||||
- (stretch goal) Encrypted kerberos support in pywinrm (bumped to 2.3)
|
||||
|
||||
- **Network** (Nate C/Peter S)
|
||||
Network
|
||||
-------
|
||||
Lead by Nate C, Peter S
|
||||
|
||||
- **Done:** Unify NetworkModules (module_utils/network.py) as much as possible
|
||||
- **Done:** Add support for config diff and replace on supported platforms (2 weeks)
|
||||
- **Done:** Support for VyOS network operating system
|
||||
- **Done:** Add support for RestConf for IOS/XE
|
||||
- **Done:** Support for Dell Networking OS10
|
||||
- **Done:** Add support for Nokia SR OS modules
|
||||
- **Done:** Network facts modules (dellos, eos, ios, iosxr, junos, nxos, openswitch, vyos)
|
||||
- **Deferred:** Network facts modules (cumulus, netvisor, sros)
|
||||
- **Deferred:** Add support for NetConf for IOS/XE
|
||||
- **Deferred:** (stretch goal) Quagga modules
|
||||
- **Deferred:** (stretch goal) Bird modules
|
||||
- **Deferred:** (stretch goal) GoBGP modules
|
||||
- **Done:** Unify NetworkModules (module_utils/network.py) as much as possible
|
||||
- **Done:** Add support for config diff and replace on supported platforms (2 weeks)
|
||||
- **Done:** Support for VyOS network operating system
|
||||
- **Done:** Add support for RestConf for IOS/XE
|
||||
- **Done:** Support for Dell Networking OS10
|
||||
- **Done:** Add support for Nokia SR OS modules
|
||||
- **Done:** Network facts modules (dellos, eos, ios, iosxr, junos, nxos, openswitch, vyos)
|
||||
- **Deferred:** Network facts modules (cumulus, netvisor, sros)
|
||||
- **Deferred:** Add support for NetConf for IOS/XE
|
||||
- **Deferred:** (stretch goal) Quagga modules
|
||||
- **Deferred:** (stretch goal) Bird modules
|
||||
- **Deferred:** (stretch goal) GoBGP modules
|
||||
|
||||
Role revamp
|
||||
-----------
|
||||
- **Implement ‘role revamp’ proposal to give users more control on role/task execution (Brian) **
|
||||
|
||||
- **https://github.com/ansible/proposals/blob/master/roles_revamp.md**
|
||||
|
||||
- **Vault** (Jtanner/Adrian)
|
||||
Vault
|
||||
-----
|
||||
Lead by Jtanner, Adrian
|
||||
|
||||
- *Extend ‘transparent vault file usage’ to other action plugins other than 'copy'(https://github.com/ansible/ansible/issues/7298)*
|
||||
**done:** https://github.com/ansible/ansible/pull/16957
|
||||
- Add ‘per variable’ vault support (!vault YAML directive, existing PR already) https://github.com/ansible/ansible/issues/13287 https://github.com/ansible/ansible/issues/14721
|
||||
- Add vault/unvault filters https://github.com/ansible/ansible/issues/12087 (deferred to 2.3)
|
||||
- Add vault support to lookups (likely deferred to 2.3 or until lookup plugins are revamped)
|
||||
- Allow for multiple vault secrets https://github.com/ansible/ansible/issues/13243
|
||||
- Config option to turn ‘unvaulting’ failures into warnings https://github.com/ansible/ansible/issues/13244
|
||||
- *Extend ‘transparent vault file usage’ to other action plugins other than 'copy'(https://github.com/ansible/ansible/issues/7298)*
|
||||
**done:** https://github.com/ansible/ansible/pull/16957
|
||||
- Add ‘per variable’ vault support (!vault YAML directive, existing PR already) https://github.com/ansible/ansible/issues/13287 https://github.com/ansible/ansible/issues/14721
|
||||
- Add vault/unvault filters https://github.com/ansible/ansible/issues/12087 (deferred to 2.3)
|
||||
- Add vault support to lookups (likely deferred to 2.3 or until lookup plugins are revamped)
|
||||
- Allow for multiple vault secrets https://github.com/ansible/ansible/issues/13243
|
||||
- Config option to turn ‘unvaulting’ failures into warnings https://github.com/ansible/ansible/issues/13244
|
||||
|
||||
- **Python3** (Toshio)
|
||||
A note here from Jason M: Getting to complete, tested Python 3 is both
|
||||
a critical task and one that has so much work and so many moving parts
|
||||
that we don’t expect this to be complete by the 2.2 release. Toshio will
|
||||
lead this overall effort.
|
||||
Python3
|
||||
-------
|
||||
Lead by Toshio
|
||||
|
||||
- Motivation:
|
||||
- Ubuntu LTS (16.04) already ships without python2. RHEL8 is coming which is also expected to be python3 based. These considerations make this high priority.
|
||||
- Ansible users are getting restless: https://groups.google.com/forum/#!topic/ansible-project/DUKzTho3OCI
|
||||
- This is probably going to take multiple releases to complete; need to get started now
|
||||
A note here from Jason M: Getting to complete, tested Python 3 is both
|
||||
a critical task and one that has so much work and so many moving parts
|
||||
that we don’t expect this to be complete by the 2.2 release. Toshio will
|
||||
lead this overall effort.
|
||||
|
||||
- Baselines:
|
||||
- We're targeting Python-3.5 and above.
|
||||
- Motivation:
|
||||
- Ubuntu LTS (16.04) already ships without python2. RHEL8 is coming which is also expected to be python3 based. These considerations make this high priority.
|
||||
- Ansible users are getting restless: https://groups.google.com/forum/#!topic/ansible-project/DUKzTho3OCI
|
||||
- This is probably going to take multiple releases to complete; need to get started now
|
||||
|
||||
- Goals for 2.2:
|
||||
- Baselines:
|
||||
- We're targeting Python-3.5 and above.
|
||||
|
||||
- Tech preview level of support
|
||||
- Controller-side code can run on Python3
|
||||
- Update: Essential features have been shown to work on Python3.
|
||||
Currently all unittests and all but three integration tests are
|
||||
passing on Python3. Code has not been line-by-line audited so bugs
|
||||
remain but can be treated as bugs, not as massive, invasive new features.
|
||||
- Almost all of our deps have been ported:
|
||||
- The base deps in setup.py are ported: ['paramiko', 'jinja2', "PyYAML", 'setuptools', 'pycrypto >= 2.6']
|
||||
- python-six from the rpm spec file has been ported
|
||||
- Python-keyczar from the rpm spec file is not.
|
||||
- Strategy: removing keyczar when we drop accelerate for 2.3. Print deprecation in 2.1.
|
||||
- Goals for 2.2:
|
||||
|
||||
- Module_utils ported to dual python3/python2(2.4 for much of it, python2.6 for specific things)
|
||||
**Mostly done:** Also not line-by-line audited but the unittests
|
||||
and integration tests do show that the most use functionality is working.
|
||||
- Add module_utils files to help port
|
||||
- Update: copy of the six library (v1.4.1 for python2.4 compat) and unicode helpers are here (ansible.module_utils._text.{to_bytes,to_text,to_native})
|
||||
- A few basic modules ported to python3
|
||||
- Stat module best example module since it’s essential.
|
||||
- Update:
|
||||
- Tech preview level of support
|
||||
- Controller-side code can run on Python3
|
||||
- Update: Essential features have been shown to work on Python3.
|
||||
Currently all unittests and all but three integration tests are
|
||||
passing on Python3. Code has not been line-by-line audited so bugs
|
||||
remain but can be treated as bugs, not as massive, invasive new features.
|
||||
- Almost all of our deps have been ported:
|
||||
|
||||
- A handful of modules like stat have been line-by-line ported. They should work reliably with few python3-specific bugs. All but three integration tests pass which means that most essential modules are working to some extent on Python3.
|
||||
- The three failing tests are: service, hg, and uri.
|
||||
- Note, large swaths of the modules are not tested. The status of
|
||||
- The base deps in setup.py are ported: ['paramiko', 'jinja2', "PyYAML", 'setuptools', 'pycrypto >= 2.6']
|
||||
- python-six from the rpm spec file has been ported
|
||||
- Python-keyczar from the rpm spec file is not.
|
||||
- Strategy: removing keyczar when we drop accelerate for 2.3. Print deprecation in 2.1.
|
||||
|
||||
- Module_utils ported to dual python3/python2(2.4 for much of it, python2.6 for specific things)
|
||||
**Mostly done:** Also not line-by-line audited but the unittests
|
||||
and integration tests do show that the most use functionality is working.
|
||||
- Add module_utils files to help port
|
||||
|
||||
- Update: copy of the six library (v1.4.1 for python2.4 compat) and unicode helpers are here (ansible.module_utils._text.{to_bytes,to_text,to_native})
|
||||
- A few basic modules ported to python3
|
||||
|
||||
- Stat module best example module since it’s essential.
|
||||
- Update:
|
||||
|
||||
- A handful of modules like stat have been line-by-line ported. They should work reliably with few python3-specific bugs. All but three integration tests pass which means that most essential modules are working to some extent on Python3.
|
||||
|
||||
- The three failing tests are: service, hg, and uri.
|
||||
- Note, large swaths of the modules are not tested. The status of
|
||||
these is unknown
|
||||
- All code should compile under Python3.
|
||||
- lib/ansible/* and all modules now compile under Python-3.5
|
||||
|
||||
- Side work to do:
|
||||
- Figure out best ways to run unit-tests on modules. Start unit-testing modules. This is going to become important so we don’t regress python3 or python2.4 support in modules (Going to largely punt on this for 2.2. Matt Clay is working on building us a testing foundation for the first half of 2.2 development so we’ll re-evaluate towards the middle of the dev cycle).
|
||||
- More unit tests of module_utils
|
||||
- More integration tests. Currently integration tests are the best way to test ansible modules so we have to rely on those.
|
||||
- All code should compile under Python3.
|
||||
- lib/ansible/* and all modules now compile under Python-3.5
|
||||
|
||||
- Side work to do:
|
||||
- Figure out best ways to run unit-tests on modules. Start unit-testing modules. This is going to become important so we don’t regress python3 or python2.4 support in modules (Going to largely punt on this for 2.2. Matt Clay is working on building us a testing foundation for the first half of 2.2 development so we’ll re-evaluate towards the middle of the dev cycle).
|
||||
- More unit tests of module_utils
|
||||
- More integration tests. Currently integration tests are the best way to test ansible modules so we have to rely on those.
|
||||
|
||||
- Goals for 2.3:
|
||||
- Bugfixing, bugfixing, bugfixing. We need community members to test,
|
||||
submit bugs, and add new unit and integration tests. I'll have some
|
||||
time allocated both to review any Python3 bugfixes that they submit
|
||||
and to work on bug reports without PRs. The overall goal is to make
|
||||
the things that people do in production with Ansible work on Python 3.
|
||||
|
||||
- **Infrastructure Buildout and Changes** (Matt Clay)
|
||||
Another note from Jason M: A lot of this work is to ease the burden of CI, CI performance, increase our testing coverage and all of that sort of thing. It’s not necessarily feature work, but it’s \*\*critical\*\* to growing our product and our ability to get community changes in more securely and quickly.
|
||||
- Bugfixing, bugfixing, bugfixing. We need community members to test,
|
||||
submit bugs, and add new unit and integration tests. I'll have some
|
||||
time allocated both to review any Python3 bugfixes that they submit
|
||||
and to work on bug reports without PRs. The overall goal is to make
|
||||
the things that people do in production with Ansible work on Python 3.
|
||||
|
||||
- **CI Performance**
|
||||
Reduce time spent waiting on CI for PRs. Combination of optimizing existing Travis setup and offloading work to other services. Will be impacted by available budget.
|
||||
Infrastructure Buildout and Changes
|
||||
-----------------------------------
|
||||
Lead by Matt Clay
|
||||
|
||||
**Done:** Most tests have been migrated from Travis to Shippable.
|
||||
Another note from Jason M: A lot of this work is to ease the burden of CI, CI performance, increase our testing coverage and all of that sort of thing. It’s not necessarily feature work, but it’s \*\*critical\*\* to growing our product and our ability to get community changes in more securely and quickly.
|
||||
|
||||
- **Core Module Test Organization**
|
||||
Relocate core module tests to ansible-modules-core to encourage inclusion of tests in core module PRs.
|
||||
- **CI Performance**
|
||||
Reduce time spent waiting on CI for PRs. Combination of optimizing existing Travis setup and offloading work to other services. Will be impacted by available budget.
|
||||
|
||||
**Deferred:** Relocation of core module tests has been deferred due to proposed changes in `modules management <https://github.com/ansible/proposals/blob/master/modules-management.md>`_.
|
||||
**Done:** Most tests have been migrated from Travis to Shippable.
|
||||
|
||||
- **Documentation**
|
||||
Expand documentation on setting up a development and test environment, as well as writing tests. The goal is to ease development for new contributors and encourage more testing, particularly with module contributions.
|
||||
- **Test Coverage**
|
||||
- **Core Module Test Organization**
|
||||
Relocate core module tests to ansible-modules-core to encourage inclusion of tests in core module PRs.
|
||||
|
||||
- Expand test coverage, particularly for CI. Being testing, this is open ended. Will be impacted by available budget.
|
||||
**Deferred:** Relocation of core module tests has been deferred due to proposed changes in `modules management <https://github.com/ansible/proposals/blob/master/modules-management.md>`_.
|
||||
|
||||
**Done:** Module PRs now run integration tests for the module(s) being changed.
|
||||
- **Documentation**
|
||||
Expand documentation on setting up a development and test environment, as well as writing tests. The goal is to ease development for new contributors and encourage more testing, particularly with module contributions.
|
||||
- **Test Coverage**
|
||||
|
||||
- Python 3 - Run integration tests using Python 3 on CI with tagging for those which should pass, so we can track progress and detect regressions.
|
||||
- Expand test coverage, particularly for CI. Being testing, this is open ended. Will be impacted by available budget.
|
||||
|
||||
**Done:** Integration tests now run on Shippable using a Ubuntu 16.04 docker image with only Python 3 installed.
|
||||
**Done:** Module PRs now run integration tests for the module(s) being changed.
|
||||
|
||||
- Windows - Create framework for running Windows integration tests, ideally both locally and on CI.
|
||||
- Python 3 - Run integration tests using Python 3 on CI with tagging for those which should pass, so we can track progress and detect regressions.
|
||||
|
||||
**Done:** Windows integration tests now run on Shippable.
|
||||
**Done:** Integration tests now run on Shippable using a Ubuntu 16.04 docker image with only Python 3 installed.
|
||||
|
||||
- FreeBSD - Include FreeBSD in CI coverage. Not originally on the roadmap, this is an intermediary step for CI coverage for OS X.
|
||||
- Windows - Create framework for running Windows integration tests, ideally both locally and on CI.
|
||||
|
||||
**Done:** FreeBSD integration tests now run on Shippable.
|
||||
**Done:** Windows integration tests now run on Shippable.
|
||||
|
||||
- OS X - Include OS X in CI coverage.
|
||||
- FreeBSD - Include FreeBSD in CI coverage. Not originally on the roadmap, this is an intermediary step for CI coverage for OS X.
|
||||
|
||||
**Done:** OS X integration tests now run on Shippable.
|
||||
**Done:** FreeBSD integration tests now run on Shippable.
|
||||
|
||||
- OS X - Include OS X in CI coverage.
|
||||
|
||||
**Done:** OS X integration tests now run on Shippable.
|
||||
|
|
|
|||
|
|
@ -1,42 +1,44 @@
|
|||
****************************
|
||||
============================
|
||||
Ansible by Red Hat, Core 2.3
|
||||
****************************
|
||||
***************************
|
||||
Target: Mid April 2017
|
||||
***************************
|
||||
============================
|
||||
**Target: Mid April 2017**
|
||||
|
||||
- **General Comments from the Core Team**
|
||||
General Comments from the Core Team
|
||||
-----------------------------------
|
||||
|
||||
- The 2.3 Ansible Core is just a little different than the past two major releases we've done. In addition to feature work, we're using part of the time for this release to reduce some of our backlog in other areas than pure development.
|
||||
- *Administration:* Clean up our GitHub repos and move to one repo so that contributions, tickets, submissions, etc are centralized and easier for both the community and the Core Team to manage.
|
||||
- *Metadata:* Move to a Metadata based system for modules. This has been discussed here: https://github.com/ansible/proposals/blob/master/modules-management.md
|
||||
- *Documentation:* We're aware that Docs have issues. Scott Butler, aka Dharmabumstead will be leading the charge on how he and we as a community can clean them up.
|
||||
- *Backlog & Stability:* We're spending some of the cycles for 2.3 trying to reduce our ticket/PR backlog, and clean up some particular areas of the project that the community has expressed particular frustrations about.
|
||||
- *Python 3:* The community and Toshio have done TONS of work getting Python 3 working. Still more to go...
|
||||
- *Features:* We still have some cool stuff coming. Check it out below. For people on the Networking side of the world, the Persistent Connection Manager will be a *huge* feature and performance gain.
|
||||
- The 2.3 Ansible Core is just a little different than the past two major releases we've done. In addition to feature work, we're using part of the time for this release to reduce some of our backlog in other areas than pure development.
|
||||
- *Administration:* Clean up our GitHub repos and move to one repo so that contributions, tickets, submissions, etc are centralized and easier for both the community and the Core Team to manage.
|
||||
- *Metadata:* Move to a Metadata based system for modules. This has been discussed here: https://github.com/ansible/proposals/blob/master/modules-management.md
|
||||
- *Documentation:* We're aware that Docs have issues. Scott Butler, aka Dharmabumstead will be leading the charge on how he and we as a community can clean them up.
|
||||
- *Backlog & Stability:* We're spending some of the cycles for 2.3 trying to reduce our ticket/PR backlog, and clean up some particular areas of the project that the community has expressed particular frustrations about.
|
||||
- *Python 3:* The community and Toshio have done TONS of work getting Python 3 working. Still more to go...
|
||||
- *Features:* We still have some cool stuff coming. Check it out below. For people on the Networking side of the world, the Persistent Connection Manager will be a *huge* feature and performance gain.
|
||||
|
||||
Repo Merge
|
||||
----------
|
||||
- Script that a submitter can run to migrate their PR **(done)**
|
||||
- Script that a committer can run to fork a PR and then merge to ansible/ansible **(mostly done)**
|
||||
- Move all the issues (remove old ones that can be removed) **(done)**
|
||||
- Enhance ansibullbot to accommodate the changes (jctanner) **(in progress, going well)**
|
||||
|
||||
- **Repo Merge**
|
||||
Metadata
|
||||
--------
|
||||
- Add metadata to the modules we ship **(done)**
|
||||
- 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)**
|
||||
|
||||
- Script that a submitter can run to migrate their PR **(done)**
|
||||
- Script that a committer can run to fork a PR and then merge to ansible/ansible **(mostly done)**
|
||||
- Move all the issues (remove old ones that can be removed) **(done)**
|
||||
- Enhance ansibullbot to accommodate the changes (jctanner) **(in progress, going well)**
|
||||
Documentation
|
||||
-------------
|
||||
- Update developing_modules **(in progress, will continue in 2.4)**
|
||||
- Set up rst skeleton for module_utils docs.
|
||||
- Plugin development docs
|
||||
- Speed up `make webdocs` https://github.com/ansible/ansible/issues/17406 **(done)**
|
||||
|
||||
- **Metadata**
|
||||
Windows
|
||||
-------
|
||||
Lead by nitzmahone
|
||||
|
||||
- Add metadata to the modules we ship **(done)**
|
||||
- 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**
|
||||
|
||||
- Update developing_modules **(in progress, will continue in 2.4)**
|
||||
- Set up rst skeleton for module_utils docs.
|
||||
- Plugin development docs
|
||||
- Speed up `make webdocs` https://github.com/ansible/ansible/issues/17406 **(done)**
|
||||
|
||||
- **Windows platform** (nitzmahone)
|
||||
- **Platform**
|
||||
|
||||
- Pipelining support **(done)**
|
||||
- Become support **(done/experimental)**
|
||||
|
|
@ -48,7 +50,7 @@ Target: Mid April 2017
|
|||
- Kerberos encryption (via notting, pywinrm/requests_kerberos/pykerberos) **(in progress, available in pywinrm post 2.3 release)**
|
||||
- Fix plugin-specific connection var lookup/delegation (either registered explicitly by plugins or ansible_(plugin)_*) **(bumped to 2.4)**
|
||||
|
||||
- **Windows modules** (nitzmahone)
|
||||
- **Modules**
|
||||
|
||||
- win_domain module **(done)**
|
||||
- win_domain_membership module **(done)**
|
||||
|
|
@ -61,93 +63,102 @@ Target: Mid April 2017
|
|||
- Updates to win_updates, adopt to core (stretch) **(bump to 2.4)**
|
||||
- Updates to win_package, adopt to core (+ deprecate win_msi) (stretch) **(bump to 2.4)**
|
||||
|
||||
- **Azure modules** (nitzmahone/mattclay)
|
||||
Azure
|
||||
-----
|
||||
Lead by nitzmahone, mattclay
|
||||
|
||||
- Ensure Azure SDK rc6/RTM work **(done)**
|
||||
- Move tests from ansible/azure_rm repo to ansible/ansible **(bump to 2.4, no CI resources)**
|
||||
- Update/enhance tests **(bump to 2.4, no CI resources)**
|
||||
- Expose endpoint overrides (support AzureChinaCloud, Azure Stack) **(bump to 2.4)**
|
||||
- Get Azure tests running in CI (stretch, depends on availability of sponsored account) **(bump to 2.4, no CI resources)**
|
||||
- azure_rm_loadbalancer module (stretch) **(bump to 2.4)**
|
||||
- Ensure Azure SDK rc6/RTM work **(done)**
|
||||
- Move tests from ansible/azure_rm repo to ansible/ansible **(bump to 2.4, no CI resources)**
|
||||
- Update/enhance tests **(bump to 2.4, no CI resources)**
|
||||
- Expose endpoint overrides (support AzureChinaCloud, Azure Stack) **(bump to 2.4)**
|
||||
- Get Azure tests running in CI (stretch, depends on availability of sponsored account) **(bump to 2.4, no CI resources)**
|
||||
- azure_rm_loadbalancer module (stretch) **(bump to 2.4)**
|
||||
|
||||
- **Networking**
|
||||
Networking
|
||||
----------
|
||||
- Code stability and tidy up **(done)**
|
||||
- Extend testing **(done)**
|
||||
- User facing documentation
|
||||
- Persistent connection manager **(done)**
|
||||
- Netconf/YANG implementation (only feature) **(done)**
|
||||
- Deferred from 2.2: Network facts modules (sros)
|
||||
|
||||
- Code stability and tidy up **(done)**
|
||||
- Extend testing **(done)**
|
||||
- User facing documentation
|
||||
- Persistent connection manager **(done)**
|
||||
- Netconf/YANG implementation (only feature) **(done)**
|
||||
- Deferred from 2.2: Network facts modules (sros)
|
||||
Python3
|
||||
-------
|
||||
|
||||
- **Python3**
|
||||
- For 2.3:
|
||||
|
||||
- For 2.3:
|
||||
- We want all tests to pass
|
||||
|
||||
- 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``
|
||||
|
||||
- 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.
|
||||
- If users report bugs on python3, these should be fixed and will prioritize our work on porting other modules.
|
||||
|
||||
- **Testing and CI** (mattclay)
|
||||
- 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.
|
||||
|
||||
- *Static Code Analysis:* Create custom pylint extensions to automate detection of common Ansible specific issues reported during code review. Automate feedback on PRs for new code only to avoid noise from existing code which does not pass.
|
||||
Testing and CI
|
||||
--------------
|
||||
Lead by mattclay
|
||||
|
||||
**Ongoing:** Some static code analysis is now part of the CI process:
|
||||
- *Static Code Analysis:* Create custom pylint extensions to automate detection of common Ansible specific issues reported during code review. Automate feedback on PRs for new code only to avoid noise from existing code which does not pass.
|
||||
|
||||
- pep8 is now being run by CI, although not all PEP 8 rules are being enforced.
|
||||
- pylint is now being run by CI, but currently only on the ansible-test portion of codebase.
|
||||
**Ongoing:** Some static code analysis is now part of the CI process:
|
||||
|
||||
- *Test Reliability:* Eliminate transient test failures by fixing unreliable tests. Reduce network dependencies by moving network resources into httptester.
|
||||
- pep8 is now being run by CI, although not all PEP 8 rules are being enforced.
|
||||
- pylint is now being run by CI, but currently only on the ansible-test portion of codebase.
|
||||
|
||||
**Ongoing:** Many of the frequent sources of test instability have been resolved. However, more work still remains.
|
||||
- *Test Reliability:* Eliminate transient test failures by fixing unreliable tests. Reduce network dependencies by moving network resources into httptester.
|
||||
|
||||
Some new issues have also appeared, which are currently being worked on.
|
||||
**Ongoing:** Many of the frequent sources of test instability have been resolved. However, more work still remains.
|
||||
|
||||
- *Enable Remaining Tests:* Implement fixes for OS X, FreeBSD and Python 3 to enable the remaining blacklisted tests for CI.
|
||||
Some new issues have also appeared, which are currently being worked on.
|
||||
|
||||
**Ongoing:** More tests have been enabled for OS X, FreeBSD and Python 3. However, work still remains to enable more tests.
|
||||
- *Enable Remaining Tests:* Implement fixes for OS X, FreeBSD and Python 3 to enable the remaining blacklisted tests for CI.
|
||||
|
||||
- *Windows Server 2016:* Add Windows Server 2016 to CI when official AMIs become available.
|
||||
**Ongoing:** More tests have been enabled for OS X, FreeBSD and Python 3. However, work still remains to enable more tests.
|
||||
|
||||
**Delayed:** Integration tests pass on Windows Server 2016. However, due to intermittent WinRM issues, the tests have been disabled.
|
||||
- *Windows Server 2016:* Add Windows Server 2016 to CI when official AMIs become available.
|
||||
|
||||
Once the issues with WinRM have been resolved, the tests will be re-enabled.
|
||||
**Delayed:** Integration tests pass on Windows Server 2016. However, due to intermittent WinRM issues, the tests have been disabled.
|
||||
|
||||
- *Repository Consolidation:* Update CI to maintain and improve upon existing functionality after repository consolidation.
|
||||
Once the issues with WinRM have been resolved, the tests will be re-enabled.
|
||||
|
||||
**Done:** A new test runner, ansible-test, has been deployed to manage CI jobs on Shippable.
|
||||
- *Repository Consolidation:* Update CI to maintain and improve upon existing functionality after repository consolidation.
|
||||
|
||||
Tests executed on PRs are based on the changes made in the PR, for example:
|
||||
**Done:** A new test runner, ansible-test, has been deployed to manage CI jobs on Shippable.
|
||||
|
||||
- Changes to a module will only run tests appropriate for that module.
|
||||
- Changes to Windows modules or the Windows connection plugin run tests on Windows.
|
||||
- Changes to network modules run tests on the appropriate virtual network device (currently supporting VyOS and IOS).
|
||||
Tests executed on PRs are based on the changes made in the PR, for example:
|
||||
|
||||
Tests executed on merges are based on changes since the last successful merge test.
|
||||
- Changes to a module will only run tests appropriate for that module.
|
||||
- Changes to Windows modules or the Windows connection plugin run tests on Windows.
|
||||
- Changes to network modules run tests on the appropriate virtual network device (currently supporting VyOS and IOS).
|
||||
|
||||
- **Amazon resources** (ryansb)
|
||||
Tests executed on merges are based on changes since the last successful merge test.
|
||||
|
||||
- Improve ec2.py integration tests **(partial, more to do in 2.4)**
|
||||
- ELB version 2 **(pushed - needs_revision [PR](https://github.com/ansible/ansible/pull/19491))**
|
||||
- CloudFormation YAML, cross-stack reference, and roles support **(done)**
|
||||
- ECS module refactor **(done)**
|
||||
- AWS module unit testing w/ placebo (boto3 only) **(pushed 2.4)**
|
||||
Amazon
|
||||
------
|
||||
Lead by ryansb
|
||||
|
||||
- **Plugin Loader**
|
||||
- Improve ec2.py integration tests **(partial, more to do in 2.4)**
|
||||
- ELB version 2 **(pushed - needs_revision [PR](https://github.com/ansible/ansible/pull/19491))**
|
||||
- CloudFormation YAML, cross-stack reference, and roles support **(done)**
|
||||
- ECS module refactor **(done)**
|
||||
- AWS module unit testing w/ placebo (boto3 only) **(pushed 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]
|
||||
Plugin Loader
|
||||
-------------
|
||||
- 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**
|
||||
ansible-ssh
|
||||
-----------
|
||||
- Add a ‘ansible-ssh’ convenience and debugging tool (will slip to 2.4)
|
||||
- Tool to invoke an interactive ssh to a host with the same args/env/config that ansible would.
|
||||
- There are at least three external versions
|
||||
|
||||
- Add a ‘ansible-ssh’ convenience and debugging tool (will slip to 2.4)
|
||||
- Tool to invoke an interactive ssh to a host with the same args/env/config that ansible would.
|
||||
- There are at least three external versions
|
||||
|
||||
- https://github.com/2ndQuadrant/ansible-ssh
|
||||
- https://github.com/haad/ansible-ssh
|
||||
- https://github.com/mlvnd/ansible-ssh
|
||||
- https://github.com/2ndQuadrant/ansible-ssh
|
||||
- https://github.com/haad/ansible-ssh
|
||||
- https://github.com/mlvnd/ansible-ssh
|
||||
|
|
|
|||
|
|
@ -1,224 +1,222 @@
|
|||
****************************
|
||||
============================
|
||||
Ansible by Red Hat, Core 2.4
|
||||
****************************
|
||||
******************************
|
||||
Target: Aug/Mid-September 2017
|
||||
******************************
|
||||
============================
|
||||
**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.
|
||||
.. contents:: Topics
|
||||
|
||||
- For example: A module that is deprecated in 2.4 will be removed in 2.8
|
||||
Administrivia and Process
|
||||
-------------------------
|
||||
- Starting with 2.4, all items that are deprecated will be removed in 4 major releases unless otherwise stated.
|
||||
|
||||
- **Python 2.4 and 2.5 support discontinuation**
|
||||
- For example: A module that is deprecated in 2.4 will be removed in 2.8
|
||||
|
||||
- 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 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**
|
||||
Python 3
|
||||
--------
|
||||
- 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 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:
|
||||
|
||||
- **Ansible-Config**
|
||||
- Dump existing config settings
|
||||
- Update / write a config entry
|
||||
- Show available options (ini entry, yaml, env var, etc)
|
||||
|
||||
- New yaml format for config
|
||||
- Extend the ability of the current config system by adding an ansible-config command and add the following:
|
||||
- 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>`_.
|
||||
|
||||
- Dump existing config settings
|
||||
Inventory
|
||||
---------
|
||||
- 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>`_.
|
||||
|
||||
- Update / write a config entry
|
||||
Facts
|
||||
-----
|
||||
- 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>`_.
|
||||
|
||||
- Show available options (ini entry, yaml, env var, etc)
|
||||
PluginLoader
|
||||
------------
|
||||
- Over the past couple releases we've had some thoughts about how
|
||||
PluginLoader might be better structured
|
||||
|
||||
- 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>`_.
|
||||
- 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.
|
||||
|
||||
- **Inventory Overhaul**
|
||||
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.
|
||||
|
||||
- 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>`_.
|
||||
Vault
|
||||
-----
|
||||
- Support for multiple vault passwords
|
||||
|
||||
- **Facts Refreshening**
|
||||
- Each decrypted item should know which secret to request
|
||||
- Support requesting credentials (password prompt) as callbacks
|
||||
|
||||
- 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>`_.
|
||||
- Ability to open and edit file with encrypted vars deencrypted, and encrypt/format on save
|
||||
|
||||
- **PluginLoader Refactor**
|
||||
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
|
||||
|
||||
- Over the past couple releases we've had some thoughts about how
|
||||
PluginLoader might be better structured
|
||||
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>`_.
|
||||
|
||||
- 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.
|
||||
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
|
||||
|
||||
- **Static Loop Keyword**
|
||||
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
|
||||
|
||||
- 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.
|
||||
Disambiguate Includes
|
||||
---------------------
|
||||
- Create import_x for ‘static includes’ (import_task, import_play, import_role)
|
||||
|
||||
- **Vault Extensibility**
|
||||
- Any directives are applied to the ‘imported’ tasks
|
||||
|
||||
- Support for multiple vault passwords
|
||||
- Create include_x for ‘dynamic includes’ (include_task, include_role)
|
||||
|
||||
- Each decrypted item should know which secret to request
|
||||
- Support requesting credentials (password prompt) as callbacks
|
||||
- Any directives apply to the ‘include’ itself
|
||||
|
||||
- Ability to open and edit file with encrypted vars deencrypted, and encrypt/format on save
|
||||
Windows
|
||||
-------
|
||||
- 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
|
||||
|
||||
- **Globalize Callbacks**
|
||||
- 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
|
||||
|
||||
- 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
|
||||
AWS
|
||||
---
|
||||
- Focus on pull requests for various modules
|
||||
- Triage existing merges for modules
|
||||
- Module work
|
||||
|
||||
- **Document Plugins**
|
||||
- elb-target-groups
|
||||
- alb*
|
||||
- ecs
|
||||
- Data Pipelines
|
||||
- VPN
|
||||
- DirectConnect
|
||||
|
||||
- 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>`_.
|
||||
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
|
||||
|
||||
- **Group Priorities**
|
||||
Google Cloud Platform
|
||||
---------------------
|
||||
- New Module: DataProc
|
||||
- Support for Cross-Region HTTP Load Balancing
|
||||
- New Module: GKE
|
||||
|
||||
- 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
|
||||
Network Roadmap
|
||||
---------------
|
||||
- Removal of ``*_template`` modules
|
||||
- Session Tracing
|
||||
- Refactor ansible-connection to cli
|
||||
- Module Work
|
||||
|
||||
- **Runtime Check on Modules for Blacklisting**
|
||||
- Declarative intent modules
|
||||
- OpenVSwitch
|
||||
|
||||
- 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
|
||||
Contributor Quality of Life
|
||||
---------------------------
|
||||
- All Core and Curated modules will work towards having unit testing.
|
||||
- More bot improvements!
|
||||
- Test Infrastructure changes
|
||||
|
||||
- **Disambiguate Includes**
|
||||
- Shippable + Bot Integration
|
||||
|
||||
- Create import_x for ‘static includes’ (import_task, import_play, import_role)
|
||||
- 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.
|
||||
|
||||
- Any directives are applied to the ‘imported’ tasks
|
||||
- Windows Server 2016 Integration Tests
|
||||
|
||||
- Create include_x for ‘dynamic includes’ (include_task, include_role)
|
||||
- Restore Windows Server 2016 integration tests on Shippable.
|
||||
|
||||
- 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.
|
||||
- Originally enabled during the 2.3 release cycle, but later disabled due to intermittent WinRM issues.
|
||||
- Depends on resolution of WinRM connection issues.
|
||||
|
||||
- Windows + Python 3 Tests
|
||||
- Windows Server Nano Integration Tests
|
||||
|
||||
- Run basic Windows tests using Python 3 as the controller.
|
||||
- Depends on resolution of WinRM Python 3 issues.
|
||||
- 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.
|
||||
|
||||
- Cloud Integration Tests
|
||||
- Windows + Python 3 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.
|
||||
- Run basic Windows tests using Python 3 as the controller.
|
||||
- Depends on resolution of WinRM Python 3 issues.
|
||||
|
||||
- Test Reliability
|
||||
- Cloud Integration Tests
|
||||
|
||||
- Further improve test reliability to reduce false positives on Shippable.
|
||||
- This continues work from the 2.3 release cycle.
|
||||
- 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.
|
||||
|
||||
- Static Code Analysis
|
||||
- Test Reliability
|
||||
|
||||
- Further expand the scope and coverage of static analysis.
|
||||
- This continues work from the 2.3 release cycle.
|
||||
- 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.
|
||||
|
|
|
|||
Loading…
Reference in a new issue