From b44fa00d33015437f198060ed46639c9bea128d2 Mon Sep 17 00:00:00 2001 From: Jason McKerr Date: Wed, 1 Jun 2016 15:54:24 -0400 Subject: [PATCH 01/16] changing to RST format. Simplifying this as a top level document that links to working roadmaps by verision --- ROADMAP.rst | 23 +++++++++++++++++++++++ 1 file changed, 23 insertions(+) create mode 100644 ROADMAP.rst diff --git a/ROADMAP.rst b/ROADMAP.rst new file mode 100644 index 0000000000..a9b24dff25 --- /dev/null +++ b/ROADMAP.rst @@ -0,0 +1,23 @@ +***************************** +Roadmap For Ansible by RedHat +***************************** +This document is now the location for published Ansible Core roadmaps. + +The roadmap will be updated by version. Based on team and community feedback, an initial roadmap will be published for a major or minor version (2.0, 2.1). Subminor versions will generally not have roadmaps published. + +2.1 was the first time Ansible has published this and asked for feedback in this manner. So feedback on the roadmap and the new process is quite welcome. The team is aiming for further transparency and better inclusion of both community desires and submissions. + +These roadmaps are the team's *best guess* roadmaps based on the Ansible team's experience and are also based on requests and feedback from the community. There are things that may not make it on due to time constraints, lack of community maintainers, etc. And there may be things that got missed, so each roadmap is published both as an idea of what is upcoming in Ansible, and as a medium for seeking further feedback from the community. Here are the good places for you to submit feedback: + + * Ansible's google-group: ansible-devel + * Ansible Fest conferences. + * IRC freenode channel: #ansible-devel (this one may have things lost in lots of conversation, so a caution). + +======================================= +Current 2.2 Roadmap is open for comment +======================================= +We are currently trying to finalize the 2.2 Roadmap, targeted for September delivery. We are seeking community feedback for 2.2. That document is here: `2.2 Roadmap Document `_ + + +**Old Roadmaps are found here:** + - `2.1 Roadmap Document `_ From 15321960be89ecee5a3d08bf02a620283d1660d2 Mon Sep 17 00:00:00 2001 From: Jason McKerr Date: Wed, 1 Jun 2016 15:55:35 -0400 Subject: [PATCH 02/16] adding docs for individual roadmap docs. Adding subdir in docsite for them. removing md file --- ROADMAP.md | 98 ------------------------ docsite/rst/roadmap/ROADMAP_2_1.rst | 67 ++++++++++++++++ docsite/rst/roadmap/ROADMAP_2_2.rst | 115 ++++++++++++++++++++++++++++ 3 files changed, 182 insertions(+), 98 deletions(-) delete mode 100644 ROADMAP.md create mode 100644 docsite/rst/roadmap/ROADMAP_2_1.rst create mode 100644 docsite/rst/roadmap/ROADMAP_2_2.rst diff --git a/ROADMAP.md b/ROADMAP.md deleted file mode 100644 index d4982369d4..0000000000 --- a/ROADMAP.md +++ /dev/null @@ -1,98 +0,0 @@ -Roadmap For Ansible by RedHat -============= -This document is now the location for published Ansible Core roadmaps. - -The roadmap will be updated by version. Based on team and community feedback, an initial roadmap will be published for a major or minor version (2.0, 2.1). Subminor versions will generally not have roadmaps published. - -This is the first time Ansible has published this and asked for feedback in this manner. So feedback on the roadmap and the new process is quite welcome. The team is aiming for further transparency and better inclusion of both community desires and submissions. - -These roadmaps are the team's *best guess* roadmaps based on the Ansible team's experience and are also based on requests and feedback from the community. There are things that may not make it on due to time constraints, lack of community maintainers, etc. And there may be things that got missed, so each roadmap is published both as an idea of what is upcoming in Ansible, and as a medium for seeking further feedback from the community. Here are the good places for you to submit feedback: - - * Ansible's google-group: ansible-devel - * Ansible Fest conferences. - * IRC freenode channel: #ansible-devel (this one may have things lost in lots of conversation, so a caution). - -2.1 Roadmap, Targeted for the End of 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 - -## 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) -* 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 ziploader instead - * Port a few essential modules to use ziploader instead of module-replacer as proof of concept - * New modules will be able to use ziploader. 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 - * ziploader is a helpful building block for: python3 porting(high priority), better code sharing between modules(medium priority) - * ziploader 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 - - - - - - - - - - - - - - - - - - - diff --git a/docsite/rst/roadmap/ROADMAP_2_1.rst b/docsite/rst/roadmap/ROADMAP_2_1.rst new file mode 100644 index 0000000000..b954690ae0 --- /dev/null +++ b/docsite/rst/roadmap/ROADMAP_2_1.rst @@ -0,0 +1,67 @@ +========================================== +2.1 Roadmap, Targeted for the End of 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 + +- 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) +- 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 ziploader instead + - Port a few essential modules to use ziploader instead of module-replacer as proof of concept + - New modules will be able to use ziploader. 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 + - ziploader is a helpful building block for: python3 porting(high priority), better code sharing between modules(medium priority) + - ziploader 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 diff --git a/docsite/rst/roadmap/ROADMAP_2_2.rst b/docsite/rst/roadmap/ROADMAP_2_2.rst new file mode 100644 index 0000000000..2bc12a8520 --- /dev/null +++ b/docsite/rst/roadmap/ROADMAP_2_2.rst @@ -0,0 +1,115 @@ +******************************** +Core 2.2, target: September 2016 +******************************** + +- **Docker** (lead by Chris Houseknecht) + - Docker_network + - Docker_volume + - Docker_file + - 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).) + - 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)) + +- **Extras split from Core (Team, Community, lead by Jason M and Jimi-c) (Estimate is yes for 2.2).** 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 ansible-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.   + - Create proposal (Jason on 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. + +- **Tweaks/Fixes** + - Add the ability to set_fact to deal with updating arrays and hashes (Jimi) + - Connection handling stuff. (Toshio K. and Brian C.): This is a stretch goal for 2.2.  It may go into 2.3 + - Change connection polling to avoid resource limitations, see [https://github.com/ansible/ansible/issues/14143](https://github.com/ansible/ansible/issues/14143) + - [https://docs.python.org/3/library/selectors.html#module-selectors](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 + +- **Cloud Modules (Ryan Brown) ** + - AWS + - Pagination for all AWS modules (generic pagination exists, but isn’t used everywhere) + - Refactoring ec2.py to be more digestible + - Fix inconsistencies with different authentication methods (STS, environment creds, ~/.aws/credentials) + - Ryan Brown and Robyn Bergeron work on bug/PR triage to reduce backlog + - Google (Ryan Brown and Tom Melendez) + - Add support for Google Cloud DNS + - Support restoring instances from snapshots + - Improved handling of scratch disks on instances + - External OpenStack (Stretch goal for this release) + - Ryan with some help from David Shrewsbury and Monty Taylor (Zuul/Openstack at RedHat). + - Support Heat stack resources + - Support LBaaS load balancers + - Azure load balancer: Feature parity for AWS ELB (Stretch Goal) + +- **VMWare (Brian, Jtanner)** + - module/inventory script: port to pyvmomi (jtanner, bcoca) + - inventory script: allow filtering ala ec2 (jtanner) (undergoing PR process) + - https://github.com/ansible/ansible/pull/15967 + - vsphere_\*: feature parity with whereismyjetpack and viasat modules  + +- **Windows platform feature parity****(Matt D)** + - 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?) + - Environment keyword support  + - win_shell/win_command + - Async support  + - (stretch goal) Pipelining  + +- **Windows-specific enhancements (Matt D)** + - Multiple Kerberos credential support (done, shepherd fix to pykerberos) + - Server 2016 testing/fixes  + - (stretch goal) Nano Server connection + module_utils working + - (stretch goal) Encrypted kerberos support in pywinrm  + +- **Network (Nate C/Peter S)** + - Unify NetworkModules (module_utils/network.py) as much as possible  + - Add support for config diff and replace on supported platforms (2 weeks) + - Network facts modules  + - OpenVSwitch modules + - Quagga modules  + - GoBGP modules (stretch) + +- **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) ** + - Extend ‘transparent vault file usage’ to other action plugins other than `copy`  + - Add ‘per variable’ vault support (!vault YAML directive, existing PR already) + - Add vault/unvault filters [https://github.com/ansible/ansible/issues/12087](https://github.com/ansible/ansible/issues/12087) + - Add vault support to lookups + - Allow for multiple vault secrets [https://github.com/ansible/ansible/issues/13243](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. + - RHEL8 is coming which has no python2 in default install.  Ubuntu (non-LTS) already ships without python2.  These considerations make this high priority. + - Natives are getting restless: [https://groups.google.com/forum/#!topic/ansible-project/DUKzTho3OCI](https://groups.google.com/forum/#!topic/ansible-project/DUKzTho3OCI) + - This is probably going to take multiple releases to complete. + - 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.  Sounds like 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). + - Goals for 2.2:   + - Controller-side code can run on python3 [but may not work in practice as targeting localhost presently uses the python that runs /bin/ansible instead of defaulting to /usr/bin/python like any other target]   + - Bcoca suggests: If we’re running controller under sys.version_info[0] >= 3, try to detect a python2 to set implicit localhost to instead of using sys.executable as workaround for modules not working with py3 yet.  + - We’ll have to make some decisions about some of our dependencies  + - The base deps in setup.py are ported: ['paramiko', 'jinja2', "PyYAML", 'setuptools', 'pycrypto >= 2.6'] + - Python-keyczar and python-six are additional deps in the rpm spec file.  Six is ported but keyczar is not. (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) + - Add module_utils files to help port -- copy of the six library (v1.4.1 for python2.4 compat), unicode helpers from ansible.utils. + - More unit tests of module_utils + - A few basic modules ported to python3 + - Stat module best example module since it’s essential. + + - Python3 integration tests -- jimi’s idea was mark some distributions as able to fail and have them run via run_tests.sh with python3 (Fedora-rawhide, latest ubuntu?)  + - Some setup.py/packaging tweaks to make it easier for users to test with py2 and py3  (ansible-playbook-py2 and py3 installed in bin?) + + - Goals for 2.3: + - Go for low hanging fruit: modules that are already python2.6+ may be easy to port to python3. + - Unfortunately, we may also have the least automated testing on these (as a large number of these are cloud modules) + - Will need to figure out how to organize “works on python3” into a cohesive set. + + - Increase number of essential modules that have been ported.  Package managers, url fetching, etc. + +- **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. + - **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. + - **Core Module Test Organization** - Relocate core module tests to ansible-modules-core to encourage inclusion of tests in core module PRs. + - **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** - Expand test coverage, particularly for CI. Being testing, this is open ended. Will be impacted by available budget. + - 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. + - Windows - Create framework for running Windows integration tests, ideally both locally and on CI. + - OS X - Include OS X in CI coverage. From 17ca68ff0ef994060dc71fd3c6a8913eac4ce326 Mon Sep 17 00:00:00 2001 From: Jason McKerr Date: Wed, 1 Jun 2016 16:02:41 -0400 Subject: [PATCH 03/16] Update ROADMAP.rst formatting stuff --- ROADMAP.rst | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/ROADMAP.rst b/ROADMAP.rst index a9b24dff25..c9c0511e9a 100644 --- a/ROADMAP.rst +++ b/ROADMAP.rst @@ -8,15 +8,16 @@ The roadmap will be updated by version. Based on team and community feedback, an 2.1 was the first time Ansible has published this and asked for feedback in this manner. So feedback on the roadmap and the new process is quite welcome. The team is aiming for further transparency and better inclusion of both community desires and submissions. These roadmaps are the team's *best guess* roadmaps based on the Ansible team's experience and are also based on requests and feedback from the community. There are things that may not make it on due to time constraints, lack of community maintainers, etc. And there may be things that got missed, so each roadmap is published both as an idea of what is upcoming in Ansible, and as a medium for seeking further feedback from the community. Here are the good places for you to submit feedback: - - * Ansible's google-group: ansible-devel - * Ansible Fest conferences. - * IRC freenode channel: #ansible-devel (this one may have things lost in lots of conversation, so a caution). + - Ansible's google-group: ansible-devel + - Ansible Fest conferences. + - IRC freenode channel: #ansible-devel (this one may have things lost in lots of conversation, so a caution). ======================================= Current 2.2 Roadmap is open for comment ======================================= -We are currently trying to finalize the 2.2 Roadmap, targeted for September delivery. We are seeking community feedback for 2.2. That document is here: `2.2 Roadmap Document `_ +We are currently trying to finalize the 2.2 Roadmap, targeted for September delivery. We are seeking community feedback for 2.2. That document is here: + +`2.2 Roadmap Document `_ **Old Roadmaps are found here:** From 570f6ed4ab3756cacd6f1d88db2844a870157e5e Mon Sep 17 00:00:00 2001 From: Jason McKerr Date: Wed, 1 Jun 2016 16:08:16 -0400 Subject: [PATCH 04/16] Update ROADMAP_2_2.rst --- docsite/rst/roadmap/ROADMAP_2_2.rst | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/docsite/rst/roadmap/ROADMAP_2_2.rst b/docsite/rst/roadmap/ROADMAP_2_2.rst index 2bc12a8520..690e553a85 100644 --- a/docsite/rst/roadmap/ROADMAP_2_2.rst +++ b/docsite/rst/roadmap/ROADMAP_2_2.rst @@ -1,7 +1,9 @@ -******************************** -Core 2.2, target: September 2016 -******************************** - +**************** +Ansible Core 2.2 +**************** +********************** +Target: September 2016 +********************** - **Docker** (lead by Chris Houseknecht) - Docker_network - Docker_volume From a81dd10646ff703083f78e1801e6a0d988e8a9e7 Mon Sep 17 00:00:00 2001 From: Jason McKerr Date: Wed, 1 Jun 2016 16:44:35 -0400 Subject: [PATCH 05/16] Update ROADMAP.rst --- ROADMAP.rst | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/ROADMAP.rst b/ROADMAP.rst index c9c0511e9a..48bba8410d 100644 --- a/ROADMAP.rst +++ b/ROADMAP.rst @@ -1,5 +1,5 @@ ***************************** -Roadmap For Ansible by RedHat +Roadmap For Ansible by Red Hat ***************************** This document is now the location for published Ansible Core roadmaps. @@ -8,6 +8,7 @@ The roadmap will be updated by version. Based on team and community feedback, an 2.1 was the first time Ansible has published this and asked for feedback in this manner. So feedback on the roadmap and the new process is quite welcome. The team is aiming for further transparency and better inclusion of both community desires and submissions. These roadmaps are the team's *best guess* roadmaps based on the Ansible team's experience and are also based on requests and feedback from the community. There are things that may not make it on due to time constraints, lack of community maintainers, etc. And there may be things that got missed, so each roadmap is published both as an idea of what is upcoming in Ansible, and as a medium for seeking further feedback from the community. Here are the good places for you to submit feedback: + - Ansible's google-group: ansible-devel - Ansible Fest conferences. - IRC freenode channel: #ansible-devel (this one may have things lost in lots of conversation, so a caution). From 08b08da614b9ead2fa4dd073264ec3bdf6010dbf Mon Sep 17 00:00:00 2001 From: Jason McKerr Date: Wed, 1 Jun 2016 16:46:38 -0400 Subject: [PATCH 06/16] Update ROADMAP_2_2.rst formatting --- docsite/rst/roadmap/ROADMAP_2_2.rst | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-) diff --git a/docsite/rst/roadmap/ROADMAP_2_2.rst b/docsite/rst/roadmap/ROADMAP_2_2.rst index 690e553a85..e9b9922849 100644 --- a/docsite/rst/roadmap/ROADMAP_2_2.rst +++ b/docsite/rst/roadmap/ROADMAP_2_2.rst @@ -5,13 +5,15 @@ Ansible Core 2.2 Target: September 2016 ********************** - **Docker** (lead by Chris Houseknecht) + - Docker_network - Docker_volume - Docker_file - 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).) - 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)) -- **Extras split from Core (Team, Community, lead by Jason M and Jimi-c) (Estimate is yes for 2.2).** 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 ansible-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.   +- **Extras split from Core (Team, Community, lead by Jason M and Jimi-c) (Estimate is yes for 2.2).** 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 ansible-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. + - Create proposal (Jason on Jimi) - Review modules for correct location (extras v core) - Extras is a completely different package (does not install with ansible) @@ -19,6 +21,7 @@ Target: September 2016 - Decide and implement release schedules between Ansible Core and Extras to ensure compatibility and longevity for modules and versions of Ansible. - **Tweaks/Fixes** + - Add the ability to set_fact to deal with updating arrays and hashes (Jimi) - Connection handling stuff. (Toshio K. and Brian C.): This is a stretch goal for 2.2.  It may go into 2.3 - Change connection polling to avoid resource limitations, see [https://github.com/ansible/ansible/issues/14143](https://github.com/ansible/ansible/issues/14143) @@ -26,6 +29,7 @@ Target: September 2016 - Code: https://github.com/kai11/ansible/blob/fix/select_fd_out_of_range_wip/lib/ansible/plugins/connection/ssh.py - **Cloud Modules (Ryan Brown) ** + - AWS - Pagination for all AWS modules (generic pagination exists, but isn’t used everywhere) - Refactoring ec2.py to be more digestible @@ -42,12 +46,14 @@ Target: September 2016 - Azure load balancer: Feature parity for AWS ELB (Stretch Goal) - **VMWare (Brian, Jtanner)** + - module/inventory script: port to pyvmomi (jtanner, bcoca) - inventory script: allow filtering ala ec2 (jtanner) (undergoing PR process) - https://github.com/ansible/ansible/pull/15967 - vsphere_\*: feature parity with whereismyjetpack and viasat modules  - **Windows platform feature parity****(Matt D)** + - 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?) - Environment keyword support  - win_shell/win_command @@ -55,12 +61,14 @@ Target: September 2016 - (stretch goal) Pipelining  - **Windows-specific enhancements (Matt D)** + - Multiple Kerberos credential support (done, shepherd fix to pykerberos) - Server 2016 testing/fixes  - (stretch goal) Nano Server connection + module_utils working - (stretch goal) Encrypted kerberos support in pywinrm  - **Network (Nate C/Peter S)** + - Unify NetworkModules (module_utils/network.py) as much as possible  - Add support for config diff and replace on supported platforms (2 weeks) - Network facts modules  @@ -69,9 +77,11 @@ Target: September 2016 - GoBGP modules (stretch) - **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) ** + - Extend ‘transparent vault file usage’ to other action plugins other than `copy`  - Add ‘per variable’ vault support (!vault YAML directive, existing PR already) - Add vault/unvault filters [https://github.com/ansible/ansible/issues/12087](https://github.com/ansible/ansible/issues/12087) @@ -80,6 +90,7 @@ Target: September 2016 - 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. + - RHEL8 is coming which has no python2 in default install.  Ubuntu (non-LTS) already ships without python2.  These considerations make this high priority. - Natives are getting restless: [https://groups.google.com/forum/#!topic/ansible-project/DUKzTho3OCI](https://groups.google.com/forum/#!topic/ansible-project/DUKzTho3OCI) - This is probably going to take multiple releases to complete. @@ -108,6 +119,7 @@ Target: September 2016 - Increase number of essential modules that have been ported.  Package managers, url fetching, etc. - **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. + - **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. - **Core Module Test Organization** - Relocate core module tests to ansible-modules-core to encourage inclusion of tests in core module PRs. - **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. From 907bdf95ca250dfbf3fd7b1d310b6b982b8be4e7 Mon Sep 17 00:00:00 2001 From: Jason McKerr Date: Wed, 1 Jun 2016 16:58:55 -0400 Subject: [PATCH 07/16] Update ROADMAP.rst more formatting. I suck at RST. --- ROADMAP.rst | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/ROADMAP.rst b/ROADMAP.rst index 48bba8410d..f601e80b46 100644 --- a/ROADMAP.rst +++ b/ROADMAP.rst @@ -1,6 +1,6 @@ -***************************** +******************************* Roadmap For Ansible by Red Hat -***************************** +******************************* This document is now the location for published Ansible Core roadmaps. The roadmap will be updated by version. Based on team and community feedback, an initial roadmap will be published for a major or minor version (2.0, 2.1). Subminor versions will generally not have roadmaps published. @@ -8,7 +8,6 @@ The roadmap will be updated by version. Based on team and community feedback, an 2.1 was the first time Ansible has published this and asked for feedback in this manner. So feedback on the roadmap and the new process is quite welcome. The team is aiming for further transparency and better inclusion of both community desires and submissions. These roadmaps are the team's *best guess* roadmaps based on the Ansible team's experience and are also based on requests and feedback from the community. There are things that may not make it on due to time constraints, lack of community maintainers, etc. And there may be things that got missed, so each roadmap is published both as an idea of what is upcoming in Ansible, and as a medium for seeking further feedback from the community. Here are the good places for you to submit feedback: - - Ansible's google-group: ansible-devel - Ansible Fest conferences. - IRC freenode channel: #ansible-devel (this one may have things lost in lots of conversation, so a caution). From a1cb25e0b7d9816b0d2231f0d6125f143daa864e Mon Sep 17 00:00:00 2001 From: Jason McKerr Date: Wed, 1 Jun 2016 16:59:16 -0400 Subject: [PATCH 08/16] Update ROADMAP.rst --- ROADMAP.rst | 1 + 1 file changed, 1 insertion(+) diff --git a/ROADMAP.rst b/ROADMAP.rst index f601e80b46..d7262bdaca 100644 --- a/ROADMAP.rst +++ b/ROADMAP.rst @@ -8,6 +8,7 @@ The roadmap will be updated by version. Based on team and community feedback, an 2.1 was the first time Ansible has published this and asked for feedback in this manner. So feedback on the roadmap and the new process is quite welcome. The team is aiming for further transparency and better inclusion of both community desires and submissions. These roadmaps are the team's *best guess* roadmaps based on the Ansible team's experience and are also based on requests and feedback from the community. There are things that may not make it on due to time constraints, lack of community maintainers, etc. And there may be things that got missed, so each roadmap is published both as an idea of what is upcoming in Ansible, and as a medium for seeking further feedback from the community. Here are the good places for you to submit feedback: + - Ansible's google-group: ansible-devel - Ansible Fest conferences. - IRC freenode channel: #ansible-devel (this one may have things lost in lots of conversation, so a caution). From 125d9838f17f5c16e9dc2cd11d794e195bc738a9 Mon Sep 17 00:00:00 2001 From: Jason McKerr Date: Wed, 1 Jun 2016 17:10:43 -0400 Subject: [PATCH 09/16] Update ROADMAP_2_2.rst --- docsite/rst/roadmap/ROADMAP_2_2.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docsite/rst/roadmap/ROADMAP_2_2.rst b/docsite/rst/roadmap/ROADMAP_2_2.rst index e9b9922849..2c48466311 100644 --- a/docsite/rst/roadmap/ROADMAP_2_2.rst +++ b/docsite/rst/roadmap/ROADMAP_2_2.rst @@ -12,7 +12,7 @@ Target: September 2016 - 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).) - 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)) -- **Extras split from Core (Team, Community, lead by Jason M and Jimi-c) (Estimate is yes for 2.2).** 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 ansible-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. +- **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 ansible-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. - Create proposal (Jason on Jimi) - Review modules for correct location (extras v core) From 58f5624a4f6a16f81d85d678b1ba56471b1085a5 Mon Sep 17 00:00:00 2001 From: Adrian Likins Date: Wed, 1 Jun 2016 18:20:33 -0400 Subject: [PATCH 10/16] formatting --- docsite/rst/roadmap/ROADMAP_2_2.rst | 185 +++++++++++++++------------- 1 file changed, 99 insertions(+), 86 deletions(-) diff --git a/docsite/rst/roadmap/ROADMAP_2_2.rst b/docsite/rst/roadmap/ROADMAP_2_2.rst index 2c48466311..c5cfff27d8 100644 --- a/docsite/rst/roadmap/ROADMAP_2_2.rst +++ b/docsite/rst/roadmap/ROADMAP_2_2.rst @@ -6,124 +6,137 @@ Target: September 2016 ********************** - **Docker** (lead by Chris Houseknecht) - - Docker_network - - Docker_volume - - Docker_file - - 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).) - - 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)) + - Docker_network + - Docker_volume + - Docker_file + - 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).) + - 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)) -- **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 ansible-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. +- **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 ansible-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. - - Create proposal (Jason on 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. + - Create proposal (Jason on 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. - **Tweaks/Fixes** - - Add the ability to set_fact to deal with updating arrays and hashes (Jimi) - - Connection handling stuff. (Toshio K. and Brian C.): This is a stretch goal for 2.2.  It may go into 2.3 - - Change connection polling to avoid resource limitations, see [https://github.com/ansible/ansible/issues/14143](https://github.com/ansible/ansible/issues/14143) - - [https://docs.python.org/3/library/selectors.html#module-selectors](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 + - Add the ability to set_fact to deal with updating arrays and hashes (Jimi) + - Connection handling stuff. (Toshio K. and Brian C.): This is a stretch goal for 2.2.  It may go into 2.3 + + - Change connection polling to avoid resource limitations, see [https://github.com/ansible/ansible/issues/14143](https://github.com/ansible/ansible/issues/14143) + - [https://docs.python.org/3/library/selectors.html#module-selectors](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 - **Cloud Modules (Ryan Brown) ** - - AWS - - Pagination for all AWS modules (generic pagination exists, but isn’t used everywhere) - - Refactoring ec2.py to be more digestible - - Fix inconsistencies with different authentication methods (STS, environment creds, ~/.aws/credentials) - - Ryan Brown and Robyn Bergeron work on bug/PR triage to reduce backlog - - Google (Ryan Brown and Tom Melendez) - - Add support for Google Cloud DNS - - Support restoring instances from snapshots - - Improved handling of scratch disks on instances - - External OpenStack (Stretch goal for this release) - - Ryan with some help from David Shrewsbury and Monty Taylor (Zuul/Openstack at RedHat). - - Support Heat stack resources - - Support LBaaS load balancers - - Azure load balancer: Feature parity for AWS ELB (Stretch Goal) + - AWS + + - Pagination for all AWS modules (generic pagination exists, but isn’t used everywhere) + - Refactoring ec2.py to be more digestible + - Fix inconsistencies with different authentication methods (STS, environment creds, ~/.aws/credentials) + - Ryan Brown and Robyn Bergeron work on bug/PR triage to reduce backlog + - Google (Ryan Brown and Tom Melendez) + + - Add support for Google Cloud DNS + - Support restoring instances from snapshots + - Improved handling of scratch disks on instances + - External OpenStack (Stretch goal for this release) + + - Ryan with some help from David Shrewsbury and Monty Taylor (Zuul/Openstack at RedHat). + - Support Heat stack resources + - Support LBaaS load balancers + - Azure load balancer: Feature parity for AWS ELB (Stretch Goal) - **VMWare (Brian, Jtanner)** - - module/inventory script: port to pyvmomi (jtanner, bcoca) - - inventory script: allow filtering ala ec2 (jtanner) (undergoing PR process) - - https://github.com/ansible/ansible/pull/15967 - - vsphere_\*: feature parity with whereismyjetpack and viasat modules  + - module/inventory script: port to pyvmomi (jtanner, bcoca) + - inventory script: allow filtering ala ec2 (jtanner) (undergoing PR process) + + - https://github.com/ansible/ansible/pull/15967 + - vsphere: feature parity with whereismyjetpack and viasat modules  - **Windows platform feature parity****(Matt D)** - - 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?) - - Environment keyword support  - - win_shell/win_command - - Async support  - - (stretch goal) Pipelining  + - 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?) + - Environment keyword support  + - win_shell/win_command + - Async support  + - (stretch goal) Pipelining  - **Windows-specific enhancements (Matt D)** - - Multiple Kerberos credential support (done, shepherd fix to pykerberos) - - Server 2016 testing/fixes  - - (stretch goal) Nano Server connection + module_utils working - - (stretch goal) Encrypted kerberos support in pywinrm  + - Multiple Kerberos credential support (done, shepherd fix to pykerberos) + - Server 2016 testing/fixes  + - (stretch goal) Nano Server connection + module_utils working + - (stretch goal) Encrypted kerberos support in pywinrm  - **Network (Nate C/Peter S)** - - Unify NetworkModules (module_utils/network.py) as much as possible  - - Add support for config diff and replace on supported platforms (2 weeks) - - Network facts modules  - - OpenVSwitch modules - - Quagga modules  - - GoBGP modules (stretch) + - Unify NetworkModules (module_utils/network.py) as much as possible  + - Add support for config diff and replace on supported platforms (2 weeks) + - Network facts modules  + - OpenVSwitch modules + - Quagga modules  + - GoBGP modules (stretch) - **Implement ‘role revamp’ proposal to give users more control on role/task execution (Brian) ** - - **https://github.com/ansible/proposals/blob/master/roles_revamp.md** + - **https://github.com/ansible/proposals/blob/master/roles_revamp.md** - **Vault (Jtanner/Adrian) ** - - Extend ‘transparent vault file usage’ to other action plugins other than `copy`  - - Add ‘per variable’ vault support (!vault YAML directive, existing PR already) - - Add vault/unvault filters [https://github.com/ansible/ansible/issues/12087](https://github.com/ansible/ansible/issues/12087) - - Add vault support to lookups - - Allow for multiple vault secrets [https://github.com/ansible/ansible/issues/13243](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'  + - Add ‘per variable’ vault support (!vault YAML directive, existing PR already) + - Add vault/unvault filters [https://github.com/ansible/ansible/issues/12087](https://github.com/ansible/ansible/issues/12087) + - Add vault support to lookups + - Allow for multiple vault secrets [https://github.com/ansible/ansible/issues/13243](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 (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. - - RHEL8 is coming which has no python2 in default install.  Ubuntu (non-LTS) already ships without python2.  These considerations make this high priority. - - Natives are getting restless: [https://groups.google.com/forum/#!topic/ansible-project/DUKzTho3OCI](https://groups.google.com/forum/#!topic/ansible-project/DUKzTho3OCI) - - This is probably going to take multiple releases to complete. - - 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.  Sounds like 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). - - Goals for 2.2:   - - Controller-side code can run on python3 [but may not work in practice as targeting localhost presently uses the python that runs /bin/ansible instead of defaulting to /usr/bin/python like any other target]   - - Bcoca suggests: If we’re running controller under sys.version_info[0] >= 3, try to detect a python2 to set implicit localhost to instead of using sys.executable as workaround for modules not working with py3 yet.  - - We’ll have to make some decisions about some of our dependencies  - - The base deps in setup.py are ported: ['paramiko', 'jinja2', "PyYAML", 'setuptools', 'pycrypto >= 2.6'] - - Python-keyczar and python-six are additional deps in the rpm spec file.  Six is ported but keyczar is not. (removing keyczar when we drop accelerate for 2.3)  print deprecation in 2.1. + - RHEL8 is coming which has no python2 in default install.  Ubuntu (non-LTS) already ships without python2.  These considerations make this high priority. + - Natives are getting restless: [https://groups.google.com/forum/#!topic/ansible-project/DUKzTho3OCI](https://groups.google.com/forum/#!topic/ansible-project/DUKzTho3OCI) + - This is probably going to take multiple releases to complete. + - 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.  Sounds like 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). + - Goals for 2.2:   - - Module_utils ported to dual python3/python2(2.4 for much of it, python2.6 for specific things) - - Add module_utils files to help port -- copy of the six library (v1.4.1 for python2.4 compat), unicode helpers from ansible.utils. - - More unit tests of module_utils - - A few basic modules ported to python3 - - Stat module best example module since it’s essential. + - Controller-side code can run on python3 [but may not work in practice as targeting localhost presently uses the python that runs /bin/ansible instead of defaulting to /usr/bin/python like any other target]   - - Python3 integration tests -- jimi’s idea was mark some distributions as able to fail and have them run via run_tests.sh with python3 (Fedora-rawhide, latest ubuntu?)  - - Some setup.py/packaging tweaks to make it easier for users to test with py2 and py3  (ansible-playbook-py2 and py3 installed in bin?) + - Bcoca suggests: If we’re running controller under sys.version_info[0] >= 3, try to detect a python2 to set implicit localhost to instead of using sys.executable as workaround for modules not working with py3 yet.  + - We’ll have to make some decisions about some of our dependencies  - - Goals for 2.3: - - Go for low hanging fruit: modules that are already python2.6+ may be easy to port to python3. - - Unfortunately, we may also have the least automated testing on these (as a large number of these are cloud modules) - - Will need to figure out how to organize “works on python3” into a cohesive set. + - The base deps in setup.py are ported: ['paramiko', 'jinja2', "PyYAML", 'setuptools', 'pycrypto >= 2.6'] + - Python-keyczar and python-six are additional deps in the rpm spec file.  Six is ported but keyczar is not. (removing keyczar when we drop accelerate for 2.3)  print deprecation in 2.1. - - Increase number of essential modules that have been ported.  Package managers, url fetching, etc. + - Module_utils ported to dual python3/python2(2.4 for much of it, python2.6 for specific things) + - Add module_utils files to help port -- copy of the six library (v1.4.1 for python2.4 compat), unicode helpers from ansible.utils. + - More unit tests of module_utils + - A few basic modules ported to python3 + + - Stat module best example module since it’s essential. + + - Python3 integration tests -- jimi’s idea was mark some distributions as able to fail and have them run via run_tests.sh with python3 (Fedora-rawhide, latest ubuntu?)  + - Some setup.py/packaging tweaks to make it easier for users to test with py2 and py3  (ansible-playbook-py2 and py3 installed in bin?) + + - Goals for 2.3: + + - Go for low hanging fruit: modules that are already python2.6+ may be easy to port to python3. + + - Unfortunately, we may also have the least automated testing on these (as a large number of these are cloud modules) + - Will need to figure out how to organize “works on python3” into a cohesive set. + + - Increase number of essential modules that have been ported.  Package managers, url fetching, etc. - **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. - - **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. - - **Core Module Test Organization** - Relocate core module tests to ansible-modules-core to encourage inclusion of tests in core module PRs. - - **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** - Expand test coverage, particularly for CI. Being testing, this is open ended. Will be impacted by available budget. - - 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. - - Windows - Create framework for running Windows integration tests, ideally both locally and on CI. - - OS X - Include OS X in CI coverage. + - **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. + - **Core Module Test Organization** - Relocate core module tests to ansible-modules-core to encourage inclusion of tests in core module PRs. + - **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** - Expand test coverage, particularly for CI. Being testing, this is open ended. Will be impacted by available budget. + - 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. + - Windows - Create framework for running Windows integration tests, ideally both locally and on CI. + - OS X - Include OS X in CI coverage. From 75d31b7a874800af002ef62929eea5b37fedeb91 Mon Sep 17 00:00:00 2001 From: Adrian Likins Date: Wed, 1 Jun 2016 18:32:46 -0400 Subject: [PATCH 11/16] formatting --- docsite/rst/roadmap/ROADMAP_2_2.rst | 26 ++++++++++++++++---------- 1 file changed, 16 insertions(+), 10 deletions(-) diff --git a/docsite/rst/roadmap/ROADMAP_2_2.rst b/docsite/rst/roadmap/ROADMAP_2_2.rst index c5cfff27d8..a7518cb9ac 100644 --- a/docsite/rst/roadmap/ROADMAP_2_2.rst +++ b/docsite/rst/roadmap/ROADMAP_2_2.rst @@ -13,7 +13,8 @@ Target: September 2016 - 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)) - **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 ansible-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. + + 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 ansible-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. - Create proposal (Jason on Jimi) - Review modules for correct location (extras v core) @@ -96,7 +97,7 @@ Target: September 2016 - 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. + 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. - RHEL8 is coming which has no python2 in default install.  Ubuntu (non-LTS) already ships without python2.  These considerations make this high priority. - Natives are getting restless: [https://groups.google.com/forum/#!topic/ansible-project/DUKzTho3OCI](https://groups.google.com/forum/#!topic/ansible-project/DUKzTho3OCI) @@ -131,12 +132,17 @@ Target: September 2016 - Increase number of essential modules that have been ported.  Package managers, url fetching, etc. -- **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. +- **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. - - **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. - - **Core Module Test Organization** - Relocate core module tests to ansible-modules-core to encourage inclusion of tests in core module PRs. - - **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** - Expand test coverage, particularly for CI. Being testing, this is open ended. Will be impacted by available budget. - - 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. - - Windows - Create framework for running Windows integration tests, ideally both locally and on CI. - - OS X - Include OS X in CI coverage. + - **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. + - **Core Module Test Organization** + Relocate core module tests to ansible-modules-core to encourage inclusion of tests in core module PRs. + - **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** + Expand test coverage, particularly for CI. Being testing, this is open ended. Will be impacted by available budget. + - 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. + - Windows - Create framework for running Windows integration tests, ideally both locally and on CI. + - OS X - Include OS X in CI coverage. From 0c629cb57747b9f1e93fa3015eb779fea054d1d5 Mon Sep 17 00:00:00 2001 From: Adrian Likins Date: Wed, 1 Jun 2016 18:35:24 -0400 Subject: [PATCH 12/16] formatting --- docsite/rst/roadmap/ROADMAP_2_2.rst | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/docsite/rst/roadmap/ROADMAP_2_2.rst b/docsite/rst/roadmap/ROADMAP_2_2.rst index a7518cb9ac..1d71bf65bf 100644 --- a/docsite/rst/roadmap/ROADMAP_2_2.rst +++ b/docsite/rst/roadmap/ROADMAP_2_2.rst @@ -13,8 +13,7 @@ Target: September 2016 - 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)) - **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 ansible-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. + 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. - Create proposal (Jason on Jimi) - Review modules for correct location (extras v core) From 0a0c4f5aaaeb1c192d1d02e3083842f37c8d50b5 Mon Sep 17 00:00:00 2001 From: Jason McKerr Date: Wed, 1 Jun 2016 18:54:53 -0400 Subject: [PATCH 13/16] Update ROADMAP_2_2.rst --- docsite/rst/roadmap/ROADMAP_2_2.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docsite/rst/roadmap/ROADMAP_2_2.rst b/docsite/rst/roadmap/ROADMAP_2_2.rst index 1d71bf65bf..711258788b 100644 --- a/docsite/rst/roadmap/ROADMAP_2_2.rst +++ b/docsite/rst/roadmap/ROADMAP_2_2.rst @@ -45,7 +45,7 @@ Target: September 2016 - Improved handling of scratch disks on instances - External OpenStack (Stretch goal for this release) - - Ryan with some help from David Shrewsbury and Monty Taylor (Zuul/Openstack at RedHat). + - Ryan with some help from David Shrewsbury (Zuul/Openstack at RedHat). - Support Heat stack resources - Support LBaaS load balancers - Azure load balancer: Feature parity for AWS ELB (Stretch Goal) From 87560a1ffccf6f259567e1727309d19cc0ed9d2f Mon Sep 17 00:00:00 2001 From: Jason McKerr Date: Wed, 1 Jun 2016 18:55:16 -0400 Subject: [PATCH 14/16] Update ROADMAP_2_2.rst --- docsite/rst/roadmap/ROADMAP_2_2.rst | 1 + 1 file changed, 1 insertion(+) diff --git a/docsite/rst/roadmap/ROADMAP_2_2.rst b/docsite/rst/roadmap/ROADMAP_2_2.rst index 711258788b..f25efdfe80 100644 --- a/docsite/rst/roadmap/ROADMAP_2_2.rst +++ b/docsite/rst/roadmap/ROADMAP_2_2.rst @@ -13,6 +13,7 @@ Target: September 2016 - 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)) - **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. - Create proposal (Jason on Jimi) From c3198aa0ed65d19e0760324de0423423759c5d43 Mon Sep 17 00:00:00 2001 From: Jason McKerr Date: Wed, 1 Jun 2016 18:56:17 -0400 Subject: [PATCH 15/16] Update ROADMAP_2_2.rst --- docsite/rst/roadmap/ROADMAP_2_2.rst | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/docsite/rst/roadmap/ROADMAP_2_2.rst b/docsite/rst/roadmap/ROADMAP_2_2.rst index f25efdfe80..c71b4fe0e3 100644 --- a/docsite/rst/roadmap/ROADMAP_2_2.rst +++ b/docsite/rst/roadmap/ROADMAP_2_2.rst @@ -12,8 +12,7 @@ Target: September 2016 - 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).) - 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)) -- **Extras split from Core (Team, Community, lead by Jason M and Jimi-c) (Targeting 2.2, could move into 2.3).** - +- **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. - Create proposal (Jason on Jimi) From 6746d7928e54173179ee02f5c5270727eaca5eeb Mon Sep 17 00:00:00 2001 From: Jason McKerr Date: Wed, 1 Jun 2016 18:56:39 -0400 Subject: [PATCH 16/16] Update ROADMAP_2_2.rst --- docsite/rst/roadmap/ROADMAP_2_2.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docsite/rst/roadmap/ROADMAP_2_2.rst b/docsite/rst/roadmap/ROADMAP_2_2.rst index c71b4fe0e3..5922cb53d1 100644 --- a/docsite/rst/roadmap/ROADMAP_2_2.rst +++ b/docsite/rst/roadmap/ROADMAP_2_2.rst @@ -12,7 +12,7 @@ Target: September 2016 - 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).) - 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)) -- **Extras split from Core (Team, Community, lead by Jason M and Jimi-c) (Targeting 2.2, could move into 2.3).* +- *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. - Create proposal (Jason on Jimi)