Context path routes in OpenShift for Managed Masters provisioned in different namespaces

Issue

When deploying Managed Masters 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

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 masters in their own projects, each master 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 master 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 master to use a specific sub-domain, set the 'Master URL Pattern' in the main Jenkins configuration page 'Manage Jenkins → Configure System' under 'Kubernetes Master Provisioning' advanced options. For example if the Operations Center domain is 'cd.example.org', the 'Master 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.

Have more questions?

0 Comments

Please sign in to leave a comment.