Is it possible to make available multiple collection versions in the same EE?
XY:
We want to allow pinning different collection versions (a specific role in a specific collection) to different hosts in a large inventory orchestrated by AWX.
Serializing the deployment, to override the ansible galaxy context during runtime, makes it very slow.
Additionally, managing a large fleet of EE (permutation of hosts and collection versions) is expensive.
Lastly, we’ve split up some 50 roles into a few collections in a monorepo whose CI published to a private Ansible Galaxy repository.
Let’s say across environments (staging, production) but even during a rolling update; Cluster of type x with y nodes where we want to apply a newer collection[.role] version for y/z nodes at a time.
Right now, we’ve implemented this capability by dynamically including roles during runtime. The collection and version is supplied as a variable. To allow “multiple” collection versions we publish each collection version with a new name; A name that includes the collection version.
e.g.
namespace.collection_major_minor_patch
This way, the same EE can handle multiple versions. As, in the context of ansible-galaxy, they are different.
We can pin a collection versions to any subset of hosts.
But, we aren’t sure this is the best approach.
It feels like an antipattern.
Hi,
It’s a kind of workaround and probably something you have constraints with but why don’t you create roles with requirements.yml that specify collection version ?
In that case, you probably dynamically install the version you wants depends on the role you call (that depends on your need , there’s a lot of “depends on”)
The end goal is to gradually rollout the next version of a collection onto hosts.
Let me elaborate:
A playbook includes namespace.collection.role version 1.0.0.
The next version , 1.0.1, is ready to be tested.
We want to include namespace.collection.role version 1.0.1 serially
We want to be able to rollback (let’s say under a Ansible blockrescue)
Right now we publish collections with the version in their names.
e.g.
namespace.collection_1_0_0
namespace.collection_1_0_1
And manage “version pinning” with group/host vars that includes these collections’ roles dynamically.
This is a workaround for ansible-galaxy limitation of installing multiple versions of the same collection.
And allow referring to these versioned collection[.roles] per host.
Working with 1:1 Ansible Role to git repo ratio is not an option. We have too many.
Maintaining a fleet of Container Image EE for each possible combination of dependencies is not an option. We have too many.
Installing the dependency on demand, during runtime, is not an option. This makes parallelism impossible, causes execution to be serial and total playbook runtime to be too long.
Depends on your constraints, except having a CICD which dynamically build your EE depends on your environments OR, managing your version through runtime and/or conditionnals… I don’t have better ideas.
I don’t have all of your technical details but on 1st solution (cicd that build EE) it means you can easily map your environment target to the corresponding EE with the right version of your collection and avoid to install collection on the runtime.
And even if you have multiple environment/stages, building 1 or 10 EE even manually tooks few minutes only.
As an example, I manage 2 EEs where the only difference is collection version and collection that are installed on one EE but not the other. No matter if I update the EE or not as AWX known where to find the EE, all my projects are still up to date with the right collections and collection version.
, there’s a lot of “depends on”)