Problems with external ingress service

[larsks]

I have case https://access.redhat.com/support/cases/#/case/03366346 open on some issues we've run into with the external ingress controller. Routes with the appropriate labels were getting match with the external ingress controller as expected, but were being assigned a hostname using the domain of the default ingress controller.

From the initial case response:

Unfortunately routes exposed on non-default IngressControllers are exposed using the default cluster domain. We are aware of the issue and have an RFE 1 open to address this IngressController behavior.

For the time being there are some options to work around this:

In case there is only a single public domain needed, please consider the Ingress objects spec.appsDomain 2 parameter. Newly created user routes will be exposed on this domain instead of the cluster default domain.

In case route creating users are aware of the exposed FQDN, please consider the Route's spec.host 3 parameter which allows to specify the FQDN for the route.

In case route creating users are not aware of the exposed FQDN please consider the Route's spec.subdomain 3 parameter, which allows configuring the left-most 'host' part of the FQDN while honoring the non-default IngressController's spec.domain.

I am trying some of the suggested workarounds to see how they work out.

[larsks]

And here's another issue:

The Service associated with the external ingresscontroller needs to be created by the ingresscontroller. We're trying to create it from manifests in the configuration repository, but that's not going to work.

This puts us -- once again -- in the position of wanting to patch an existing resource, which we can't do with ArgoCD.

A short term solution is probably an ArgoCD post-sync hook (https://argo-cd.readthedocs.io/en/stable/user-guide/resource_hooks/); we can install a job that will take care of patching the resource.

[larsks]

This has been resolved by recent pull requests.