[patch] Don't set SLS domain by default

[rawa-resul]

Issue

• Reported by customers and IBMers

Description

• Newer versions of OCP implement stricter rules when it comes to api versioning. SLS up until 3.12.0 creates a Route using v1 as apiVersion but it needs to be route.openshift.io/v1 otherwise fails. This is fixed in 3.12.1.
• By default, the sls role would set the sls_domain which forces SLS to create a Route. This logic is wrong. By removing this we also create a workaround for SLS up to 3.12.0 to bypass this issue.

Test Results

• Ran the sls role to install SLS without providing sls_domain --> Installed SLS using service url.
• Ran the sls role to install SLS with providing sls_domain --> Installed SLS and created Route.
• Ran the sls role to install SLS without providing sls_domain then ran role again with sls_domain --> Installed SLS and created Route.
• Ran the sls role to install SLS with providing sls_domain then ran role again without sls_domain --> Installed SLS and created Route; second run did not remove Route.
• Attached this branch of api-licensing in my branch of the CLI and ran a mas install successfully.

---

⚠️ Notes for Reviewers

• Ensure you have understood the PR guidelines in the Playbook before proceeding with a review.
• Ensure all sections in the PR template are appropriately completed.

[durera]

Did we set up existing MAS instances to use the route that we are now effectively deprecating (in most scenario)?

I assume the result of this change is that the slscfg that will be used in most installs will now be one that is using the kubernetes service.

What is the expected behaviour in this scenario:

• Install first MAS instance + SLS using older version of the CLI
• Install second MAS instance using new version of the CLI

When the second install runs it will refresh the SLS instance ... and presumably this will result in the removal of the route. So did we set up the first MAS instance using that route?

[rawa-resul]

Did we set up existing MAS instances to use the route that we are now effectively deprecating (in most scenario)?

I assume the result of this change is that the slscfg that will be used in most installs will now be one that is using the kubernetes service.

What is the expected behaviour in this scenario:

• Install first MAS instance + SLS using older version of the CLI
• Install second MAS instance using new version of the CLI

When the second install runs it will refresh the SLS instance ... and presumably this will result in the removal of the route. So did we set up the first MAS instance using that route?

When you install using an older version of CLI, SLS will have a Route. If you then install over it using a newer CLI with this change then nothing will happen to the Route. The domain field will still be present in the LicenseService CR. This is the behaviour I was aiming for. I did not want to break anyone's environment if they already have a Route because they could be using it off-cluster too.

When patching the LicenseService CR with a spec that doesn't have the domain field would not remove it. By default, Kubernetes only updates fields that are in both the local template and CR, and adds the remaining new fields.

Moreover, SLS does not currently have the logic of removing a Route when the domain field is removed from the CR. This was discovered during this work and I will add that into SLS.