In skupper 2.0, a special ConfigMap with the label skupper.io/label-template can be used to configure the skupper controller for kubernetes to apply labels to specific resources that it creates. When a label template ConfigMap has a data field for "name" or "kind", the skupper controller will only apply the ConfigMap labels to resources matching those properties.
In the case of more dynamic resources, like v2alpha1.Listeners and the Service(s) they create, it would be nice to be able to apply user-provided labels without a per-resource ConfigMap.
Example: A user has a Listener with exposePodsByName set, and needs to to target the set of Services created by this Listener. The existing scheme cannot accommodate this.
proposed solution
A two part plan:
- Add an additional label-template ConfigMap data field "labelSelector". When set, the labels from the ConfigMap will be applied only to resources matching that labelSelector. Invalid labelSelectors will be logged and ignored.
- Add skupper provided labels to identify resources created by the skupper controller. Continuing the above example, we would add an
internal.skupper.io/listener: <listener-name> label to Listener services.
After implementing these, a user could create a ConfigMap with labels skupper.io/label-template and com.acme.foo/custom-label, and a data field labelSelector: "internal.skupper.io/listener = my-listener". Services skupper creates for the Listener "my-listener" would get the com.acme.foo/custom-label label.
In skupper 2.0, a special ConfigMap with the label
skupper.io/label-templatecan be used to configure the skupper controller for kubernetes to apply labels to specific resources that it creates. When a label template ConfigMap has a data field for "name" or "kind", the skupper controller will only apply the ConfigMap labels to resources matching those properties.In the case of more dynamic resources, like v2alpha1.Listeners and the Service(s) they create, it would be nice to be able to apply user-provided labels without a per-resource ConfigMap.
Example: A user has a Listener with exposePodsByName set, and needs to to target the set of Services created by this Listener. The existing scheme cannot accommodate this.
proposed solution
A two part plan:
internal.skupper.io/listener: <listener-name>label to Listener services.After implementing these, a user could create a ConfigMap with labels
skupper.io/label-templateandcom.acme.foo/custom-label, and a data fieldlabelSelector: "internal.skupper.io/listener = my-listener". Services skupper creates for the Listener "my-listener" would get the com.acme.foo/custom-label label.