Adjust ACM to retrieve normalised application name by querying applicationsForRuntime

[tobiscr]

Description

Effective by September 30th, 2024 (the end of Q3), UCL (formerly known as Compass) will be deprecating and completely removing the application naming normalisation logic currently ensured by us as part of the response of the applicationsForRuntime GraphQL query.

This change is in response to an issue originally reported back to you in 2020: kyma/issues/10070. As indicated by Jan Mędrek's comment on the GitHub issue, it appears the necessary adaptations to your components should have already been implemented here: reconciler/issues/419.

AC:

• Get in touch with UCL team (https://github.com/NickyMateev) and clarify what the fix on ACM has to be (how to get now the normalised application name?)
• Verify ACM implementation and ensure the normalised application name is NOT retrieved by using the Compass applicationsForRuntime response (eventually is a fix required on ACM side for generating a normalised application name).

[koala7659]

Main points:

Naming applications:

The Director will stop returning friendly (normalized) name for Applications connected to Kyma runtimes runtime. As a result we can have Applications with non-DNS compliant names that will we will be able to create in Kubernetes cluster.
From now on Compass Runtime Agent should normalise and use normalised name on Kyma side.

Runtime Agent should append some kind of unique suffix so as to eliminate potential naming conflicts with existing Application CR names

Runtime Agent should apply its custom normalization logic for Application CR resource names only if runtime is labeled with isNormalized=false.

Code to normalize application name - to use on Compass Runtime Agent side is here

Runtime Agent periodically fetches all applications from Compass. It should tweak it's reconciliation algorithm a bit and stop comparing application names and rather it should compare by application IDs when trying to determine if an application already exists.

Labeling runtimes:

Runtime Agent should make sure to call Compass and label the respective runtime with <app_id>_eventURL and the value being the actual absolute /v1/events URL (we could rethink the name of the label, but it should contain the app ID)
For backwards compatibility reasons it should be made sure that after introducing this change for all pre-existent Application CRs their respective eventURLs are sent to Compass (maybe the regular update of Application CRs should ensure that)
Upon removal of an Application CR from the Kyma runtime the Runtime Agent should ensure that the runtime is unlabeled with the eventURL

[koala7659]

We came into conclusion our normalization that the task consists actually of two different requirements:

1. Make Kyma runtime resistent to upcoming compass change by adding name normalization in the side on compass runtime agent.
2. Allow to support multiple applications with the same name that for example belong to different system types (commerce and c4c)

The first requirement is the easiest one - just copy normalizator code and make compass runtime agent use it during synchronisation
The second one - is about changing identification method of the application across all AppConnector from name to some uniqueID to avoid conflicts.
We HAVE NEVER supported such feature until now. It is basically new feature request.
Implementation will not be easy and must be done carefully across all the module as it can affect current workloads.

I suggest splitting the task:

Part 1:

1. Implement now only first part of the story and release new version of the module before October
2. To make sure everything will work as before - add some checks that detects duplicate application names and in such a case fail synchronisation
3. In Application Connector documentation add note that "Names of your systems connected to Kyma must be unique in BTP and must not contain special characters".

Part 2:

1. Make another issue to support in App Connector multiple applications with the same names and identification based on some kind of unique ID, proritize it and put it into development queue.

[tobiscr]

Follow up action to support two (or more) applications with the same name: #362