Release corresponding versions of ascender-ee

[Klaas-]

Please confirm the following

• I have checked the current issues for duplicates.
• I understand that Ascender is open source software provided for free and that I might not receive a timely response.

Feature type

New Feature

Feature Summary

At the moment ascender-ee always uses latest (the only tag that exists). I would like to suggest to tag releases that correspond to the versions of ascender and release them with the ascender version tag. Then also use those EEs for control plane. This should prevent ascender and ascender-ee being incompatible to one-another in case there are any changes in "latest" that an older ascender version does not deal with.

Select the relevant components

• UI
• API
• Docs
• Collection
• CLI
• Other

Steps to reproduce

Browse to https://github.com/ctrliq/ascender-ee/pkgs/container/ascender-ee and see there is only latest tag.

Current results

only latest

Sugested feature result

• latest
• 25.3.5
• 25.3.6
• ...

Additional information

No response

[cigamit]

We currently don't tag the ascender-ee images that way, as the images are rebuilt nightly automatically. The reason for this, is to ensure that all system packages are updated to remove any vulnerabilities found (we have some gov clients where security is paramount). If you were to pin the control plane to a specific version, you wouldn't be able to update it without upgrading Ascender, even if patches were applied to the EE.

We can probably come up with a different way of doing this and still allowing the nightly updates. I will discuss it with the team.

[Klaas-]

why are daily updates on the EE more important than say daily updates on the ascender app container? :) I mean we could do that and just do a daily combined release of both YY.M.D versioning was also the idea for real awx if it ever gets another public release :D

The problem I see two problems with the current setup is that it will pull the container before each run

1. Connectivity issues, if there is a problem ascender will stop working properly -- workaround to set Pull to "Only if missing"
2. Installing an older version -- if for some reason you need to install an older version of ascender it may be incompatible with the latest ee currently released

[Klaas-]

also I am not saying stop defaulting to latest, I am saying release a fitting/tested EE for each version you release in addition to daily latest ones

[cigamit]

Daily updates of the Ascender containers is also something we are looking into, it is just going to need a lot more automated testing before we would be comfortable with that (which is being worked on). Currently I just keep an eye on things and will ensure to release a new build if a High vuln comes along in the container base image. The EE container is pretty static otherwise, so it was an easy decision, thought we did run into one issue in the past with some new package compatibilities which required a work around.

There is an option in the installer to set the pull policy, but really we aren't as concerned with connectivity issues. Most of our clients are using an internal registry, which they use automation to push the images to, and the installer pulls from there. We recommend that for everyone, as it solves a lot of issues. At least until we get our own version of the upstream hub out the door (complete rewrite in Go). Once I split the installer, I will probably add a playbook to simplify the entire process (internal registry and image pull).

[Klaas-]

Yeah, usually this would be the same here, but our local cache broke for downloading new containers from ghcr, that's when I noticed it's trying to pull that all the time. So I generally agree, but I still think it would be a good idea not to check for a new latest version on every container create with that EE -- not sure maybe schedule a daily pull and leave it untouched for the rest of the day; something like that; but I am not sure if it's easily doable on the ascender side of things. If this becomes a pain point I will do a deeper investigation, for now I'll concentrate on fixing the local cache :)

[Klaas-]

Tags like this arealso assumed by the operator:

https://github.com/ctrliq/ascender-operator/blob/23b655f463ac75a0b97b71fdf6f7f72409398fc2/roles/installer/defaults/main.yml#L284-L285

I'll do a PR to remove that, if you decide to include tagged EE versions at a later point; we can readd it.