With #293 we introduced a change that allow controllers deployed to multiple clusters to correctly identify https edges and tunnel (think of multiple devs running the same app in k8s on their own machines). However, because we used the ingress UID, we broke the case where the same service is used in multiple ingresses in the same namespace - essentially one of them will set the tunnel labels to its own and the rest will be un-routable. Here, we move to use a different identifier, e.g. service UID, with the premise that these are uniquely enough (both across the cluster and between clusters).
How
Extract the service UID and use it to set the https edge/tunnel labels.
related: #291
What
With #293 we introduced a change that allow controllers deployed to multiple clusters to correctly identify https edges and tunnel (think of multiple devs running the same app in k8s on their own machines). However, because we used the ingress UID, we broke the case where the same service is used in multiple ingresses in the same namespace - essentially one of them will set the tunnel labels to its own and the rest will be un-routable. Here, we move to use a different identifier, e.g. service UID, with the premise that these are uniquely enough (both across the cluster and between clusters).
How
Extract the service UID and use it to set the https edge/tunnel labels.
Breaking Changes
None