Fix scheduled discovery when allNamespaces property is true

[tzoratto]

Relates to #428 #448 #465

Type of request

Bug fix

Behavior

When

• the property spring.cloud.kubernetes.discovery.all-namespaces is true
• and @EnableScheduling has been set

the service/pod discovery never see any addition/deletion of pods for a given service in a different namespace that the one the spring boot admin server is in.

How to reproduce

1. In a namespace A, deploy a spring boot application (deployment and service) with one replica
2. In a namespace B, deploy a spring boot admin server with the following annotations (as per the documentation of this project) :
   @SpringBootApplication @EnableAdminServer @EnableDiscoveryClient @EnableScheduling, the property spring.cloud.kubernetes.discovery.all-namespaces set to true (and the required rbac configuration)
3. You should see your spring boot application properly reported in spring boot admin server, with 1 instance
4. Scale up your spring boot application (let's say 2 replicas)
5. Even after 30 secondes (the default scheduled interval), spring boot admin server still shows 1 spring boot application with 1 instance

Expected behavior

When these conditions are met we expect to see the dynamically updated list of instances in spring boot admin server without restarting it.

Please let me know if there is anything wrong with this patch, I had never used this lib before this morning so I might be missing something obvious. Adding inAnyNamespace() definitely fixes the issue though

Thanks

[ryanjbaxter]

Is Spring Boot Admin using HeartBeatEvent in some way to update the list of services?

cc: @Haybu

[tzoratto]

apparently yes as adding inAnyNamespace() here (which only causes a HeartBeatEvent to be published) successfully fixes the issue and update the data within spring boot admin server

that's also how it works with discovery based on consul as far as I understand it (https://cloud.spring.io/spring-cloud-consul/2.1.x/multi/multi_spring-cloud-consul-discovery.html)

[tzoratto]

any more feedback ? Until this fix is released I have to maintain a custom implementation of KubernetesCatalogWatch to make it work

[spencergibb]

Please me patient. The next release isn't scheduled until May.

[tzoratto]

of course, I just wanted to know if the fix looks good for you or if I have to change something before it can be merged

[tzoratto]

Hello there, I'm still waiting for feedback :)

[weliff]

:+1 I have the same problem in the description :/

[tzoratto]

hi @weliff unfortunately as you can see I have had no feedback at all on this 20 LOC PR for more than 2 months now (I still don't understand why). The only solution for now is to create a custom bean implementing KubernetesCatalogWatch doing what this PR does, I hope you managed to do so 👍

[spencergibb]

/cc @ryanjbaxter @Haybu

[llaszkie]

Hi! We can see it is merged - great! :-) But do you @ryanjbaxter plan also to release it - like soon - in scope of 1.1?

[ryanjbaxter]

Yes our next Hoxton service release will contain this change. You can find dates here https://github.com/spring-cloud/spring-cloud-release/milestones