ansible/community.general
1
0
Fork 0
mirror of https://github.com/ansible-collections/community.general.git synced 2024-09-14 20:13:21 +02:00
Code Releases Activity

Merge branch 'mckerrj-devel' into devel

Browse source
This commit is contained in:
Jason McKerr 2016-06-02 14:24:21 -04:00
commit 58b431e02f
2 changed files with 121 additions and 90 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

7
ROADMAP.rst
View file

@ -1,6 +1,6 @@
***************************** *******************************
Roadmap For Ansible by RedHat Roadmap For Ansible by Red Hat
***************************** *******************************
This document is now the location for published Ansible Core roadmaps. 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. 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,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. 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: 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's google-group: ansible-devel
- Ansible Fest conferences. - Ansible Fest conferences.
- IRC freenode channel: #ansible-devel (this one may have things lost in lots of conversation, so a caution). - IRC freenode channel: #ansible-devel (this one may have things lost in lots of conversation, so a caution).

204
docsite/rst/roadmap/ROADMAP_2_2.rst
View file

@ -5,113 +5,143 @@ Ansible Core 2.2
Target: September 2016 Target: September 2016
********************** **********************
- **Docker** (lead by Chris Houseknecht) - **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.   - Docker_network
- Create proposal (Jason on Jimi) - Docker_volume
- Review modules for correct location (extras v core) - Docker_file
- Extras is a completely different package (does not install with ansible) - 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).)
- Library dependencies - 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))
- 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 (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)
- 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** - **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 - Add the ability to set_fact to deal with updating arrays and hashes (Jimi)
- Change connection polling to avoid resource limitations, see [https://github.com/ansible/ansible/issues/14143](https://github.com/ansible/ansible/issues/14143) - Connection handling stuff. (Toshio K. and Brian C.): This is a stretch goal for 2.2.  It may go into 2.3
- [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 - 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) ** - **Cloud Modules (Ryan Brown) **
- AWS
- Pagination for all AWS modules (generic pagination exists, but isn’t used everywhere) - AWS
- Refactoring ec2.py to be more digestible
- Fix inconsistencies with different authentication methods (STS, environment creds, ~/.aws/credentials) - Pagination for all AWS modules (generic pagination exists, but isn’t used everywhere)
- Ryan Brown and Robyn Bergeron work on bug/PR triage to reduce backlog - Refactoring ec2.py to be more digestible
- Google (Ryan Brown and Tom Melendez) - Fix inconsistencies with different authentication methods (STS, environment creds, ~/.aws/credentials)
- Add support for Google Cloud DNS - Ryan Brown and Robyn Bergeron work on bug/PR triage to reduce backlog
- Support restoring instances from snapshots - Google (Ryan Brown and Tom Melendez)
- Improved handling of scratch disks on instances
- External OpenStack (Stretch goal for this release) - Add support for Google Cloud DNS
- Ryan with some help from David Shrewsbury and Monty Taylor (Zuul/Openstack at RedHat). - Support restoring instances from snapshots
- Support Heat stack resources - Improved handling of scratch disks on instances
- Support LBaaS load balancers - External OpenStack (Stretch goal for this release)
- Azure load balancer: Feature parity for AWS ELB (Stretch Goal)
- 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)
- **VMWare (Brian, Jtanner)** - **VMWare (Brian, Jtanner)**
- module/inventory script: port to pyvmomi (jtanner, bcoca)
- inventory script: allow filtering ala ec2 (jtanner) (undergoing PR process) - module/inventory script: port to pyvmomi (jtanner, bcoca)
- https://github.com/ansible/ansible/pull/15967 - inventory script: allow filtering ala ec2 (jtanner) (undergoing PR process)
- vsphere_\*: feature parity with whereismyjetpack and viasat modules 
- https://github.com/ansible/ansible/pull/15967
- vsphere: feature parity with whereismyjetpack and viasat modules 
- **Windows platform feature parity****(Matt D)** - **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  - 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?)
- win_shell/win_command - Environment keyword support 
- Async support  - win_shell/win_command
- (stretch goal) Pipelining  - Async support 
- (stretch goal) Pipelining 
- **Windows-specific enhancements (Matt D)** - **Windows-specific enhancements (Matt D)**
- Multiple Kerberos credential support (done, shepherd fix to pykerberos)
- Server 2016 testing/fixes  - Multiple Kerberos credential support (done, shepherd fix to pykerberos)
- (stretch goal) Nano Server connection + module_utils working - Server 2016 testing/fixes 
- (stretch goal) Encrypted kerberos support in pywinrm  - (stretch goal) Nano Server connection + module_utils working
- (stretch goal) Encrypted kerberos support in pywinrm 
- **Network (Nate C/Peter S)** - **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) - Unify NetworkModules (module_utils/network.py) as much as possible 
- Network facts modules  - Add support for config diff and replace on supported platforms (2 weeks)
- OpenVSwitch modules - Network facts modules 
- Quagga modules  - OpenVSwitch modules
- GoBGP modules (stretch) - Quagga modules 
- GoBGP modules (stretch)
- **Implement ‘role revamp’ proposal to give users more control on role/task execution (Brian) ** - **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) ** - **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. - Extend ‘transparent vault file usage’ to other action plugins other than 'copy' 
- RHEL8 is coming which has no python2 in default install.  Ubuntu (non-LTS) already ships without python2.  These considerations make this high priority. - Add ‘per variable’ vault support (!vault YAML directive, existing PR already)
- Natives are getting restless: [https://groups.google.com/forum/#!topic/ansible-project/DUKzTho3OCI](https://groups.google.com/forum/#!topic/ansible-project/DUKzTho3OCI) - Add vault/unvault filters [https://github.com/ansible/ansible/issues/12087](https://github.com/ansible/ansible/issues/12087)
- This is probably going to take multiple releases to complete. - Add vault support to lookups
- 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). - Allow for multiple vault secrets [https://github.com/ansible/ansible/issues/13243](https://github.com/ansible/ansible/issues/13243)
- Goals for 2.2:   - Config option to turn ‘unvaulting’ failures into warnings https://github.com/ansible/ansible/issues/13244
- 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) - **Python3 (Toshio):**
- Add module_utils files to help port -- copy of the six library (v1.4.1 for python2.4 compat), unicode helpers from ansible.utils. 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.
- 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?)  - RHEL8 is coming which has no python2 in default install.  Ubuntu (non-LTS) already ships without python2.  These considerations make this high priority.
- 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?) - 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:  
- Goals for 2.3: - 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]  
- 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. - 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 
- **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. - The base deps in setup.py are ported: ['paramiko', 'jinja2', "PyYAML", 'setuptools', 'pycrypto >= 2.6']
- **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. - 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.
- **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. - Module_utils ported to dual python3/python2(2.4 for much of it, python2.6 for specific things)
- **Test Coverage** - Expand test coverage, particularly for CI. Being testing, this is open ended. Will be impacted by available budget. - Add module_utils files to help port -- copy of the six library (v1.4.1 for python2.4 compat), unicode helpers from ansible.utils.
- 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. - More unit tests of module_utils
- Windows - Create framework for running Windows integration tests, ideally both locally and on CI. - A few basic modules ported to python3
- OS X - Include OS X in CI coverage.
- 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.