Configuration Watcher - Add The Ability To Notify Apps Based On Labels

[fnarvaez-applydigital]

Is your feature request related to a problem? Please describe.
Currently, the configuration uses a list of service names to specify which services needs to be notified when a configmap change. This approach requires manual updates whenever services are added, removed, or renamed, leading to potential maintenance overhead and errors.

Describe the solution you'd like
Modify the configuration to use label selectors instead of a list of service names. This can be done by specifying the desired labels in a selector field. For example:

apiVersion: v1
kind: ConfigMap
metadata:
  name: feature-config
  namespace: your-namespace
  annotations:
    spring.cloud.kubernetes.configmap.label.selector: |
      { labelA: "a", labelB: "b" }
data:
  ....

Using label selectors instead of explicitly listing service names can make it more flexible and scalable. This approach allow to dynamically select services based on their labels, which can be particularly useful in environments where services are frequently added, removed, or changed.

[ryanjbaxter]

Are you referring to this functionality?
https://docs.spring.io/spring-cloud-kubernetes/reference/spring-cloud-kubernetes-configuration-watcher.html#_monitoring_configmaps_and_secrets

[fnarvaez-applydigital]

@ryanjbaxter that's right

[ryanjbaxter]

I think that would be a worthwhile enhancement we can look into. Right now we use the DiscoveryClient to go through and notify the application and that works on the service name. I think we could get all services from the DiscoveryClient and that should have the metadata and we can notify based on labels. I would have to double check that.

If you are interested in submitting a PR with this functionality that would be amazing.

Otherwise I might be able to take a look at it once we begin work on our next major release.

[wind57]

I spent some time yesterday looking at this one. DiscoveryClient can give back two things : names of the services and instances of a single service (endpoints under a service).

Those instances are the ones that contain the service metadata, including labels. But, those can be disabled via spring.cloud.kubernetes.discovery.metadata.add-labels=false or, they can have a prefix added, via spring.cloud.kubernetes.discovery.metadata.labels-prefix=false. In addition, we would be doing quite a lot of work, only get rid of 99% of it once we have the response. What I mean is that we get a List<ServiceInstance>, but really we need a List<ServiceWithLabels> (and the mapping is not 1-1) This complicates things.

imho, we should introduce a new method in our custom k8s native discovery client (an nowhere else: not in fabric8, not in discovery server), that would return the "pure" services with metadata they have.

But I've only spent about 2h yesterday on this subject.

[ryanjbaxter]

Thanks for the initial feedback.

Couple of thoughts.

1.) I assume if you disable labels via metadata.add-labels you probably shouldn't use labels as a way of notifying the apps ;). This can be documented.

2.) If you use labels-prefix you should then add that prefix in your labels configured on the config map. Again we can document that.

What I mean is that we get a List, but really we need a List (and the mapping is not 1-1) This complicates things

I am not sure why this is needed but I have looked at it less than you have, so maybe when I look at it or see the code I would understand better. Either way, I am not sure I see a reason here not to do this based on what you have said.

[wind57]

Either way, I am not sure I see a reason here not to do this based on what you have said.

I took a fresh pass over the code today in the morning and... (surprise) I agree with you now :). I'd like to work on this, and hope to do it fairly soon.