Set the GPS route's ingressController shard
Currently routes created for GPS are not explicitly assigned an ingressController shard. This means the routes will be handled by the default
ingress controller, normally reserved for system routes.
We need the operator to set explicitly which ingressController shard to use. This is done via a route annotation in webeos clusters, e.g. webeos.cern.ch/router-shard: apps-shard-1
However:
- better not hardcode the annotation name and make it configurable, so we have some flexibility in case we dissociate GPS from webeos itself
- in order to support exposing doc sites to TN, some apps will need to use another shard such as
apps-shard-tn
; or for scalability we might have aapps-shard-2,3...
in the future. So the shard needs to be configurable per site, but not in a way that is modifiable by users. We could for instance allow admins to override the value directly on the route (see webeos procedure: https://okd-internal.docs.cern.ch/cluster-flavours/webeos/operations/allow-technical-network-access/#enable-ingress-from-tn-to-webeos-sites)
This means the operator should have a configurable default value to use as the router-shard annotation value, but operator should not overwrite it if admins later change it manually.
For troubleshooting or for users to know about their site's TN visibility it would probably be useful to report about what's the current shard in the GPS status (e.g. in an Exposed
condition?), but that's a nice-to-have rather than a requirement.
OTOH we should not wait too long before implementing proper router shard support because changing the shard will incur a few minutes of downtime: this is due to DNS updates propagating much slower than the router configuration: there will be a mismatch for a few minutes, resulting in HTTP 503 errors.