- 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)
@ -24,6 +25,7 @@ Target: September 2016
- 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)
- 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.
@ -106,13 +116,16 @@ Target: September 2016
- 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.
Adrian Likins
8 years ago
committed by