feat(controller): ConfigMap image mapping override

[derekhiggins]

feat: ConfigMap image mapping overrides for LLS Distro

Implements a mechanism for the Llama Stack Operator to read and apply
LLS Distribution image updates from a ConfigMap, enabling independent patching
for security fixes or bug fixes without requiring a new LLS Operator.

- Add ImageMappingOverrides field to LlamaStackDistributionReconciler
- Implement parseImageMappingOverrides() to read image-overrides from ConfigMap
- Support symbolic name mapping (e.g., rh-dev) to specific images
- Included unit tests

The operator now reads image overrides from the 'image-overrides' key in the
operator ConfigMap, supporting YAML format with version-to-image mappings.
Overrides take precedence over default distribution images and are refreshed
on each reconciler initialization.

Closes: RHAIENG-1079
Signed-off-by: Derek Higgins <[email protected]>

---

Fix operator config ConfigMap watching

o Add operator config detection in configMapUpdatePredicate
o Update feature flags when operator config changes
o Trigger reconciliation of all LlamaStackDistributions on operator config change

---

Also

 fix: Replace deprecated corev1.Endpoints with discoveryv1.EndpointSlice 

Fix for deprecated Endpoints Generated by cursor but output tested here here , search for the string "Found 1 pods in namespace"

[rhuss]

Thanks for the PR, great stuff :). Here's my first round of review.

My main points are:

• We must not reference RHODS in this upstream operator. Why and where do you need the RHODS version ? (i can't really see why this is needed). This is really important.
• Probably not related to this PR, nevertheless: The enabling of network policies should not be a 'feature flag' (which is about enabling/disabling feature that has its own configuration), but a 'configuration option' (you can combine both, feature flag and configuration option but you should not 'misuse' a feature flag as configuration of a permanent feature)

[derekhiggins]

We must not reference RHODS in this upstream operator. Why and where do you need the RHODS version ? (i can't really see why this is needed). This is really important.

Lets deal with this first as the rest of the PR might change based on this, So the objective of this PR is to allow the operator to set a new image for a specific major/minor version. The code needs to know the RHODS version in order to know if a config map for rh-dev-2.25 is relevant i.e. to stop using it when we move onto rh-dev-2.26.

If ^ is correct then perhaps at least part of this PR should be mid/downstream ?

[rhuss]

I wonder why we need to add the version number at all to the key. Couldn't the operator just unconditionally pick up the image under the key rh-dev for the default image and the image just is either a 2.25 or 2.26 version ? Does the operator really need to know about this version or just deploy the configured image ?

[derekhiggins]

I wonder why we need to add the version number at all to the key. Couldn't the operator just unconditionally pick up the image under the key rh-dev for the default image and the image just is either a 2.25 or 2.26 version ? Does the operator really need to know about this version or just deploy the configured image ?

Because we've asserted "The major and minor versions of the LLS distribution and the LLS operator must match, but the z-stream version can differ.", if the minor version is upgrade (either manually or automatically) then the operator needs to know to stop using the image and instead switch over to the default for the new version.

If what we want is to unconditionally use a specific image, we already have distribution.image for that in the llsd resource

[derekhiggins]

Updated to remove the inclusion of the version number in the mapping key

[mergify]

This pull request has merge conflicts that must be resolved before it can be merged. @derekhiggins please rebase it. https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/syncing-a-fork

[VaishnaviHire]

@mergify rebase

[mergify]

rebase

✅ Branch has been successfully rebased

[VaishnaviHire]

@rhdedgar @rhuss Is this PR okay to merge?

[derekhiggins]

rebased to prompt CI into running (small change to the way the context is passed into ParseImageMappingOverrides to keep the linter happy)

[VaishnaviHire]

@mergify rebase

[mergify]

rebase

✅ Branch has been successfully rebased

[VaishnaviHire]

@derekhiggins The image overrides tests continue to fail

[derekhiggins]

@derekhiggins The image overrides tests continue to fail

Thanks @VaishnaviHire I hadn't noticed the failure, I'll take a look

[derekhiggins]

@derekhiggins The image overrides tests continue to fail

Thanks @VaishnaviHire I hadn't noticed the failure, I'll take a look

Done,

[VaishnaviHire]

@mergify rebase

[mergify]

rebase

✅ Branch has been successfully rebased

[nathan-weinberg]

@mergify rebase

[mergify]

rebase

✅ Branch has been successfully rebased

[VaishnaviHire]

@mergify rebase

[mergify]

rebase

✅ Branch has been successfully rebased

Dismissing Russ review, as it was based on an older version
After it was made requirements were discuses and the PR adjusted appropriately.
He isn't available at the moment to Ack the PR and we'd like to merge it this week.