spring-cloud-kubernetes: Unable to start application that has kubernetes discovery flag disabled

Describe the bug Since the introduction of KubernetesCatalogWatchAutoConfiguration in 3.0.1 we can not start our application anymore. The mentioned autoconfiguration will look for beans that we have not defined yet.

We are running our application on a kubernetes cluster, with discovery enabled, but kubernetes discovery disabled for now.

Since it is tied to discovery with @ConditionalOnDiscoveryEnabled, shouldn’t the autoconfig get an extra condition @ConditionalOnKubernetesDiscoveryEnabled as well?

There were other autoconfigs introduced as well that might be impacted

About this issue

  • Original URL
  • State: closed
  • Created a year ago
  • Comments: 17 (15 by maintainers)

Most upvoted comments

Now that I think about this a little, I am torn apart if this should really have the @ConditionalOnKubernetesDiscoveryEnabled 😐

It would not change much if we add it, sure. But:

  • if you do not want it to be picked-up, just add spring.cloud.kubernetes.discovery.catalog-services-watch.enabled=false
  • you are pointing out to the kubernetes-native implementation of catalog watch, that came only in the 3.x.x release. The fabric8 implementation, that existed before the kubernetes-native one, does not have the @ConditionalOnKubernetesDiscoveryEnabled. This is how it looks in 2.1.x branch:
@Configuration(proxyBeanMethods = false)
@ConditionalOnDiscoveryEnabled
@ConditionalOnProperty(name = "spring.cloud.kubernetes.enabled", matchIfMissing = true)
@AutoConfigureAfter({ Fabric8AutoConfiguration.class })
public class KubernetesCatalogWatchAutoConfiguration {

	@Bean
	@ConditionalOnMissingBean
	@ConditionalOnProperty(name = "spring.cloud.kubernetes.discovery.catalog-services-watch.enabled",
			matchIfMissing = true)
	public KubernetesCatalogWatch kubernetesCatalogWatch(KubernetesClient client,
			KubernetesDiscoveryProperties properties) {
		return new KubernetesCatalogWatch(client, properties);
	}

}

I am more inclined towards not having it, simply for compatibility reasons: since if we do add it now and someone has in their code : spring.cloud.kubernetes.discovery.enabled=false, they would not get this bean, and they would expect to. So this will be a breaking change in their configs. If I get approval from Ryan that this is indeed needed (I am kind of OK either way), then such a breaking change is fine, since it fixes a bug.


Your issue under-covered some other problems we have, but me, personally (and I am not part of this team that decides such things), would not add it. @ryanjbaxter I need a sane advice here please… If we decide to add it, we need it in fabric8 auto-config also.

It would work, yes; but then it under-covers another problem that we have. I’m preparing a PR where I’ll present my case and we can discuss further if you do not mind