Issue

When deploying Managed controllers in different namespaces the Router in Openshift rejects the route with a similar stacktrace than the one below:

A route in another namespace holds <DNS> and is older than <NAMESPACE_WHERE_TRYING_TO_DEPLOY_THE_MANAGED_MASTER> 

Reason: HostAlreadyClaimed

Environment

• CloudBees CI on Modern cloud platforms
• OpenShift

Resolution

At the moment of writing this Knowledge Base article, the official documentation at CloudBees for context path based routes in Openshift specifies the following below.

To provision controllers in their own projects, each controller must use a specific sub-domain. For example, if the Operations Center domain is 'cd.example.org' and the URL is 'https://cb.example.org/cjoc/', a controller dev1 is needed to use the sub-domain 'dev1.cd.example.org' or 'dev1-cd.example.org'. It is often preferable to use the latter if using a wild card certificates for domain 'example.org'.

To configure each controller to use a specific sub-domain, set the 'controller URL Pattern' in the main Jenkins configuration page 'Manage Jenkins → Configure System' under 'Kubernetes controller Provisioning' advanced options. For example if the Operations Center domain is 'cd.example.org', the 'controller URL Pattern' would be 'https://*-cd.example.org/*/'.

However, in Openshift 4.4 and up version supports the route admission policy, where administrators and application developers can run applications in multiple namespaces with the same domain name. For this, you can edit the .spec.routeAdmission field of the ingress controller resource variable using the following command:

oc -n openshift-ingress-operator patch ingresscontroller/default --patch '{"spec":{"routeAdmission":{"namespaceOwnership":"InterNamespaceAllowed"}}}' --type=merge

• Note For the moment CloudBees has not validated this potencial workaround, although some customers have already confirmed that it indeed workarounds the issue. An internal ticket has been submitted from the Support Team at CloudBees to update the official documentation. The documentation will be updated once the workaround is confirmed by the Engineering team.