Ansible Community team has been working on the community Execution Environment (EE) image. To more and in details about the EE, please have a look at the the Getting started guide.
The power of Execution Environments unfolds when users build their images themselves but we’d like to provide a very basic community image for our users to play with when learning EEs or for those users who want to use EEs but they use only ansible-core, so there’ll be one ready to use.
IMPORTANT: the goal is not to provide an EE with community.* collections included.
Now we are seeking feedback from the community on the following questions:
2. Where do we want to publish it (as a GitHub package): under the ansible or ansible-community GitHub organizations that will affect the package namespace in its URL.
3. What do we want the image to contain? Only ansible-core or ansible-core + selected collections?
For now we’re considering the following collections:
- ansible.netcommon
- ansible.posix
- ansible.utils
- ansible.windows
The criteria is that those ones are very basic and general: e.g. ansible.posix provides the firewalld module.
We would like to keep the set of the collections as minimal as possible to avoid dependency conflicts, though having only ansible-core would be also acceptable.
We could also throw out some or add something else (but please keep the goal of the image in mind when suggesting).
4. How often we want to built it? As an option, it could be bound to Ansible package minor releases.
Please share what you think on the aforesaid questions.
ansible-core + those collections: +1 because they cover a lot of base stuff many may want but at the same it’s not much, so it satisfies the goal of the image. Having only ansible-core should be also fine.
I would create two EEs: a truly minimal with just ansible-core, and a base one with ansible-core, ansible.utils, ansible.posix, and ansible.windows. All generally useful parts of ansible.netcommon have been moved to ansible.utils (like all the useful filters and tests for working with IP addresses). Also with at least one it should be easy to add more community EEs.
I would rebuild the EEs nightly, to make sure that the system packages in the images are fresh. Only rebuilding weekly or even less frequent can quickly result in an accumulation of security vulnerabilities.
I like @Spredzy 's suggestion to call them: community-ee-minimal (with core only), and community-ee-base (with those several collections @felixfontein mentioned)
In which repository do we want to have its configuration stored, i.e. the execution-environment.yml file?
Another +1 for ansible-community/images
Where do we want to publish it (as a GitHub package): under the ansible or ansible-community GitHub organizations that will affect the package namespace in its URL.
I will be reaching out to try to confirm what’s the real objective behind the issue and if Quay.io is actually being moved. Maybe the @AWX team can chime in on the topic considering their awx-ee is hosted there as well.
I would +1 Quay.io unless GitHub Container Registry (GHCR) provides enough workflow benefits to outweigh having yet another community dependency on it. If GHCR it is, then +1 to ansible-community namespace.
What do we want the image to contain? Only ansible-core or ansible-core + selected collections?
+1 to having two ee, a minimal and a base one.
Although I would suggest base to have a few more collections considering we are doing a minimal one, they both look quite minimal otherwise… we could aim to what seemed to be the most used collections according to the stats shown in Ansible Community Day Boston 2023 by the Galaxy team.
Adding to ansible.posix, ansible.utils, ansible.windows, we could consider the following:
community.general (it’s a big one, but also, the most used, why not include it? really curious about this considering we have a minimal alternative)
community.docker
kubernetes.core
community.crypto
How often we want to built it? As an option, it could be bound to Ansible package minor releases.
How about community-ee-minimal and community-ee (no -base). It’s not a base EE if it has other collections in it and the terms base and core are already kind of overloaded.
I would leave out ansible.windows. It would be better in a purpose-built collection with winrm and other necessary dependencies to interact with Windows hosts and perhaps community.windows as well.
@Leo the set of collections should be as minimal as possible to avoid dependency conflicts (because Builder also installs all dependencies specified in their requirements’txt’s)
@gotmax23 I’m not sure if base is still associated with core widely. I would prefer keeping some prefix there for consistency in naming.
About ansible.windows: +0 for having/leaving as it won’t probably conflict in terms of dependencies with other stuff. If there’s a demand in future for windows specialized EE, we can build it but for the purpose of the image it’s imo fine to have it there. Remember, the power of EE unfolds when you build it;)
Trying to summarize here:
1 repo for the execution environment - GitHub - ansible-community/images
2 quay vs GHCR still TBD
3 two EEs - ommunity-ee-minimal with core only and community-ee-base with core, ansible.utils, and ansible.posix (TBD)
4 - publish nightly
So other than Quay, can we finalize:
name of the second ee? (with or without -base or something else)
final list of included collections. Seems like we don’t NEED to have the ansible.windows included so maybe we keep it out and at some point consider a third windows-focused collection?
I didn’t get any concrete replies yet, just left a message for the AWX/Controller team to see how they are interpreting the message and how it affects awx-ee. Let’s see if they are aware and what’s their take.
If they don’t know I will try to reach the actual people in the ticket and seek clarification from them.
Let’s release community-ee-minimal as soon as we can… based on the most recent stable-2.15 core release, and assuming people can pull it from Quay.io w/o the need for a login, let’s use that for now.
now community-ee-minimal is now available as ghcr.io/ansible-community/community-ee-minimal:latest.
what is the goal of having it exactly on quay.io? Let’s maybe have it on ghcr permanently?
I guess it is now time to decide on why and if we want Quay.io or ghcr (under ansible-community namespace)? What are problems that Quay.io is solving and ghcr is not?
Folks please share your feedback and vote in here and the supportive reasons for the choice in the thread.
I’d opt for quay.io just off the dogfood principle, however I am not against ghcr.io. Right now people know to look for redhat related images on quay, so that makes sense, but do we have a reason to move to ghcr.io? atm at least as a container registery, What are the advantages?
I will say an important point to raise that the creator-ee is hosted on ghcr.io, I am not opposed to either quay or ghcr but we should stick to one hosting platform and possibly in a single repo so its easier for users to subscribe if there are updates.
EDIT: Looks like the creator-ee is duplicated between ghcr and quay but the default setting in the extension points to ghcr.io
I have no preference for ghcr vs. quay. As long as it’s not Docker Hub… Traditionally most ansible related images were on quay, but that doesn’t mean we have to use it forever.
GHCR might be easier if we’re using Github Actions to build images, as we won’t have to deal with auth tokens and such. We could also easily push the image to both registries if we want to make it more available or just can’t decide .
Traditionally most ansible related images were on quay, but that doesn’t mean we have to use it forever.