Execution environment definition, creation, and management

[wenottingham]

ISSUE TYPE

• Feature Idea

(I expect subtasks will live off of here.)

SUMMARY

Ansible is moving to collections. Collections have dependencies. Dependencies complicate providing coherent execution of playbooks. We have historically hidden this complexity for cloud modules, but it seeps in occasionally (especially with Azure), and we leave custom venv creation entirely to our users. This is complicated by the fact that the AWX operator is often not the playbook author. Our users aren’t venv and pip experts; we need to make things easier for them where we can.

Hence, AWX needs to expand to provision and manage execution environments, including how they get to execution nodes.

What is an execution environment?

An execution environment definition consists of:

• an ansible version
• a python version (defaults to system python)
• a tiny set of required python libraries
• zero or more collections (optional, see below). This could be sourced from the requirements present in a playbook repo
• python dependencies of those collections

The concept of specifying a set of collections for an environment is to resolve and install their dependencies. The collections themselves are not required to be in the environment (and arguably should not be.)

An execution environment is built from this definition. This will likely be a container image.

What should we provide to users?

1. Create a standardized definition of an execution environment. Given our ecosystem and the cloud world at large, I sense… YAML.
2. Create a tool, that given this definition, creates an execution environment as a container image. It would do so by reading any provided collections, extracting the dependency information, and then creating the environment in a container image.

• it should warn/error on dependency issues
• it should warn/error if the collections do not claim compatibility with the provided Ansible version

3. Add execution environments as first-order objects in AWX
4. Read environment definitions from SCM as needed
5. Manage how execution environments get on execution nodes. This is likely via container pull.
6. Replace the existing ‘virtual environment’ construct with this

[AlanCoding]

I was going to try to post a bunch of links here from Ansible core. The roadmap for 2.10 isn't enlightening for me. Maybe there's a longer-term roadmap somewhere? Some requests, like ansible/ansible#58266, are counter-productive.

There are some surprising formats used for Ansible module python requirements

• https://github.com/ansible/ansible/blob/5349b3ae4c056ca5f5a32bc41a5e7eb9d60a7f46/lib/ansible/modules/cloud/docker/docker_volume_info.py#L39
• https://github.com/ansible/ansible/blob/fb9720429119cd56a7dde6d06600a082b4ab19c3/lib/ansible/modules/network/panos/_panos_match_rule.py#L36

Would these involve into some standard spec used for this? Would this involve user specification of python requirements? Do they need to be presented with module / collection requirements are suggestions?

But module requirements are also a separate subject from collection requirements. You should not need all requirements to install a collection and use an inventory plugin from it, even if the modules have a requirement (take the AWX collection as an example, that is exactly the case with it).

Another subject I'm very worried about is collection dependency resolution. You might be able to write out a spec, but that spec might contradict itself. This is possible with collection requirements themselves. Add python requirements (particularly non-necessary ones), and the likelihood of that increases.

[AlanCoding]

Another link #4844

(expect this to be closed)

[unlikelyzero]

@shanemcd moved this to needs_test, putting this onto folks for visibility. @kdelee @tiagodread @yagomarques

[kdelee]

ISSUE TYPE

• Feature Idea

(I expect subtasks will live off of here.)

SUMMARY

Ansible is moving to collections. Collections have dependencies. Dependencies complicate providing coherent execution of playbooks. We have historically hidden this complexity for cloud modules, but it seeps in occasionally (especially with Azure), and we leave custom venv creation entirely to our users. This is complicated by the fact that the AWX operator is often not the playbook author. Our users aren’t venv and pip experts; we need to make things easier for them where we can.

Hence, AWX needs to expand to provision and manage execution environments, including how they get to execution nodes.

What is an execution environment?

An execution environment definition consists of:

• an ansible version
• a python version (defaults to system python)
• a tiny set of required python libraries
• zero or more collections (optional, see below). This could be sourced from the requirements present in a playbook repo
• python dependencies of those collections

this is all covered in builder features

The concept of specifying a set of collections for an environment is to resolve and install their dependencies. The collections themselves are not required to be in the environment (and arguably should not be.)

An execution environment is built from this definition. This will likely be a container image.

What should we provide to users?

1. Create a standardized definition of an execution environment. Given our ecosystem and the cloud world at large, I sense… YAML.
2. Create a tool, that given this definition, creates an execution environment as a container image. It would do so by reading any provided collections, extracting the dependency information, and then creating the environment in a container image.

• it should warn/error on dependency issues
• it should warn/error if the collections do not claim compatibility with the provided Ansible version

the above are all covered in builder features

1. Add execution environments as first-order objects in AWX
   done

2. Read environment definitions from SCM as needed
   ???

3. Manage how execution environments get on execution nodes. This is likely via container pull.
   done

4. Replace the existing ‘virtual environment’ construct with this
   done

I think we can close this issue as it has been broken up into other issues