Add Ansible Execution Environment container (for AAP/AWX/Tower) alongside other containers in Github Packages

[mk-fg]

Hi,

AVD currently ships execution-environment.yml in the repository root, and general-purpose container packages (based on python slim container), but don't seem to have corresponding Execution Environment (EE) containers (based on ansible-runner) for Ansible Automation Platform (AWX/Tower) under Github Packages.

Which is why, if I understand everything correctly, currently setting up e.g. self-contained AWX with an AVD project would look like this:

• Start with k8s with AWX running on it (seem to be the only official way to run it for non-testing/devel purposes).
• Setup docker-registry running on the same k8s, with some tricks to be able to give AWX an internal container URL (i.e. "repo/project/image-name:tag").
• Setup a build environment with ansible and e.g. docker.
• Clone AVD repository there, run ansible-build to build AVD EE container for AWX.
• Push produced container in docker-registry setup in k8s via earlier step.
• Go into AWX WebUI and point it to an EE container from that registry.

This seems quite complicated, compared to this:

• Start with same k8s and AWX running on it.
• Go into AWX WebUI and point it to an official EE container from AVD repository, e.g. ghcr.io/aristanetworks/avd/execution-environment:v4.10.0

That's much simpler and more convenient than the other process above, and doesn't require every AWX setup to build their own exactly-same container, and publish it in their own registry somewhere (maybe also signing up with and relying on an extra third party).

Containers seem to be documented as a preview feature at the moment, so maybe a good time to add this extra container there as well, without creating any confustion.

https://avd.sh/en/stable/docs/getting-started/avd-aap.html#ansible-builder also documents the build and import of an EE container, but seem to be outdated in that execution-environment.yml is now included in the repo.
And same as also mentioned above, seems strange to say "This guide uses Docker Hub as the container registry, but you may use any container registry that is accessible by AAP" and document redundant build process there, when container can be packaged in the official repo, same as code, and that whole section replaced by "Use this URL: ghcr.io/aristanetworks/avd/...".

Not sure if there might be a technical reason to omit this type of a container that I don't know about, as opposed to others.

Thanks.

[ClausHolbechArista]

The ansible-builder guide is correct. The yml file you refer to is there to tell ansible-builder what is needed when someone adds arista.avd as a collection in their EE definition.

You do not need to clone or install anything around avd. Just install ansible-builder, create an EE definition file in the format your version of builder requires, and then include arista.avd as one of the collections. Ansible builder will pull down the collection from galaxy and find the execution environment yaml file to figure out which dependencies must be included as well.

We do not have any current plans on maintaining EE images.

[mk-fg]

Ah, my bad, guess I didn't realize that ansible will auto-build EE when collection is added like that.

[mk-fg]

After reading your response more carefully and tinkering with AWX a bit, I see that you only meant that "Clone AVD repository there" step is unnecessary (can use simple execution-environment.yml with arista.avd requirement in there instead), while I optimistically misread that as "galaxy will magically install pyavd from collections/requirements.yml" (it won't).

So building and pushing custom EE image somewhere is still a requirement to run AVD on AWX, which I hoped might be simplified.
"We do not have any current plans on maintaining EE images" is a pretty clear "no" on that - unfortunate but fair enough.
Thanks for clearing that up, apologies for initial misunderstanding.

[ClausHolbechArista]

It is a fair ask to get EE from us.
We would have to test them and maintain all the various versions of Ansible, so we have decided not to take that on for now. I would expect ansible-builder to get closer integrated in AWX/AAP, so it becomes more like an "EE designer" in the UI. At least that is what I would want :)