After keptn configure domain, an already exposed bridge is no longer accessible

[christian-kreuzberger-dtx]

Steps to reproduce:

1. Install Keptn 0.6.2 (full installation)
2. expose bridge using keptn configure bridge --action=expose - bridge is exposed at (e.g.) bridge.keptn.1.2.3.4.xip.io
3. change domain using keptn configure domain 1.2.3.4.nip.io
4. Try to access bridge using the new domain https://bridge.keptn.1.2.3.4.nip.io (does not work)

Interesting enough, the old domain (using xip.io) still works for Keptn's bridge.

Some more data

$ kk get vs
NAME     GATEWAYS                        HOSTS                                             AGE
api      [public-gateway.istio-system]   [api.keptn.1.2.3.4.nip.io api.keptn]   4m50s
bridge   [public-gateway.istio-system]   [bridge.keptn.1.2.3.4.xip.io]                131m

Work-around

Right now, the user has to execute the following commands to make the setup work again:

keptn configure bridge --action=lockdown
keptn configure bridge --action=expose

Possible Fix

I guess one of the two following variants should work:

• keptn configure domain should output a warning, that the user needs to manually check and update all other virtual services (e.g., bridge, but also onboarded services)
• keptn configure domain needs to also update other virtual services, not just the API vs (which is handled via a kubectl apply).

Please note, I did not check if this also happens when using nginx-ingress (e.g., when using the quality-gates installation), but I guess nginx-ingress is handling this differently