- 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>`_)
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.
- 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)
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.
- 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
- Baselines:
- We're targeting Python-3.5 and above.
- Goals for 2.2:
- 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.
- 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.
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.
**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>`_.
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.
