Configmap and application in other namespace then Spring Cloud Kubernetes Configuration Watcher about spring-cloud-kubernetes HOT 15 CLOSED

It depends on what version you are. We have this functionality for a while, see this. Thank you.

from spring-cloud-kubernetes.

Hello and thanks for your answer. I'm using 3.04. I actually saw that issue, but thought it was a different situation. It is not clear to me where and how I need to configure the POD, the Watcher or bouth from that discussion. Could you point me to some documentation?

I tried adding namespace in the watcher configuration on configmap (otp is the namespace where the watcher is and resesok-paratransit is namespace B in my question)

apiVersion: v1
data:
  application.yaml: |
    spring:
      rabbitmq:
        host: resesok-rabbitmq
        port: 5672
      cloud:
        kubernetes:
          configuration:
            watcher:
              namespaces: otp,resesok-paratransit

from spring-cloud-kubernetes.

How do you deploy the watcher? via a deployment.yaml, I assume?

See here, where we document this.

If that still does not make sense: you need this in the spec.template.spec.containers.env:

env:
  - name: SPRING_CLOUD_KUBERNETES_RELOAD_NAMESPACES_0
    value: "resesok-paratransit"

in the deployment.yaml of the configuration watcher itself.

Makes sense?

from spring-cloud-kubernetes.

I can confirm that this change make the watcher see changes on namespace resesok-paratransit, but now I don't see changes on namespace otp (namespace A in my question). I tried adding bouth namespaces in the value but that made the watcher crash.

from spring-cloud-kubernetes.

env:
  - name: SPRING_CLOUD_KUBERNETES_RELOAD_NAMESPACES_0
    value: "resesok-paratransit"
  - name: SPRING_CLOUD_KUBERNETES_RELOAD_NAMESPACES_1
     value: "otp"

like this?

from spring-cloud-kubernetes.

I can verify that this works well for refreshing in both namespaces. The output on the log in the watcher is not very beautiful, it give the same error as I saw before, with the difference that it updates well. Should I configure the error out of my log? The log just keeps showing up in loop all the time.

2024-02-07T11:47:02.785Z ERROR 1 --- [dels.V1Secret-1] i.k.c.informer.cache.ReflectorRunnable   : class io.kubernetes.client.openapi.models.V1Secret#Reflector loop failed unexpectedly

io.kubernetes.client.openapi.ApiException: 
	at io.kubernetes.client.openapi.ApiClient.handleResponse(ApiClient.java:973) ~[client-java-api-17.0.2.jar:na]
	at io.kubernetes.client.openapi.ApiClient.execute(ApiClient.java:885) ~[client-java-api-17.0.2.jar:na]
	at io.kubernetes.client.informer.SharedInformerFactory$1.list(SharedInformerFactory.java:222) ~[client-java-17.0.2.jar:na]
	at io.kubernetes.client.informer.cache.ReflectorRunnable.run(ReflectorRunnable.java:91) ~[client-java-17.0.2.jar:na]
	at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source) ~[na:na]
	at java.base/java.util.concurrent.FutureTask.runAndReset(Unknown Source) ~[na:na]
	at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Unknown Source) ~[na:na]
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) ~[na:na]
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) ~[na:na]
	at java.base/java.lang.Thread.run(Unknown Source) ~[na:na]

from spring-cloud-kubernetes.

eh weird, the logs come from the client we use, not from our code

This should not be there in logs, no. If you can provide a minimal, reproducible example, I can take a closer look.

But that seems like a different issue anyway, so feel free to close this one (as it seems to have fixed the issue) and open a new one with the logs.

from spring-cloud-kubernetes.

I will do that, for me this is good enough because it is working. To bad about the logs, but they don't seem to be a show stopper for me. I will create an issue here and if it is prioritized someone can fix it in future release.

All your help is very appreciated you fixed my problem.

from spring-cloud-kubernetes.

Little comment, if I go to spring.io then I end up on different documentation from the one you linked me to.

spring.io

You gave me this

from spring-cloud-kubernetes.

no worries at all!

The documentation is still sort of a mystery for me too :) (I am not a Spring employee, just a random contributor here). may be @ryanjbaxter finds the time to explain this too.

from spring-cloud-kubernetes.

Created issue #1574

from spring-cloud-kubernetes.

These are just different versions of the documentation for different releases. The version on spring.io you linked to is for the 3.1.0 release the version @wind57 pointed to is for the 3.0.x release. The content for the section on the configuration watcher should be virtually the same between the two releases I believe.

from spring-cloud-kubernetes.

I understand, but if the documentation of the configuration is still valid, then I think this documentation should remain in the documentation of 3.1.0?

from spring-cloud-kubernetes.

Ah those documentation changes were merged into the 3.1.x branch (main) after the 3.1.0 release. They are there in our 3.1.1 snapshot documentation and will be published with the next release of that branch
https://docs.spring.io/spring-cloud-kubernetes/reference/3.1-SNAPSHOT/spring-cloud-kubernetes-configuration-watcher.html

from spring-cloud-kubernetes.

This makes more sense, thanks for the feedback.

from spring-cloud-kubernetes.