[QUESTION] Different behaviour kubernetes-client-config / kubernetes-client-all #1654
Comments
|
Can you provide a complete, minimal, verifiable sample that reproduces the problem? It should be available as a GitHub (or similar) project or attached to this issue as a zip file. |
|
Hello, Here the zip. It includes the Dockerfile I use to build the app Here the kube deployment used : apiVersion: apps/v1
kind: Deployment
metadata:
name: demo
spec:
replicas: 1
selector:
matchLabels:
app: demo
template:
metadata:
labels:
app: demo
spec:
containers:
- name: demo
image: "harbor.local/demo:latest"
imagePullPolicy: Always
resources:
limits:
cpu: 250m
memory: 512Mi
requests:
cpu: 50m
memory: 512Mi
env:
- name: SPRING_APPLICATION_NAME
value: demo
ports:
- name: webservice
containerPort: 9090
protocol: TCPNo matter the configMap as it's never read, NPE before |
|
The problem is indeed there, I can re-produce it. Thank you for the sample. Indeed the dependencies are to be blamed here. I am going to dig a little bit more, so that my conclusions are not vague and will update this post once I am done. |
|
To me : this is a bug. @ryanjbaxter I'll try to explain what is going on, so please advise with your input. Since OP is having this dependency: this will bring Because of the first one, we will trigger since discovery is not enabled, we will return After that, we will trigger Now because We are returning null there in the sense that "I don't care about these properties, since I am not going to use them anyway, because discovery is not enabled". At least this is how I understood the code. If that is indeed the case, we can still bind (create) them, with defaults and other properties that are present for them. Much like we do in specifically in the |
|
I have a proposal for a fix here and I tested it against the OPs sample. |
|
I guess I am wondering why we are even registering |
|
ha! you're right, I've updated the PR to remove it. |
|
Hello guys, thanks for the reactivity :) I see 3.1.2 and spring-cloud-dependencies 2023.0.2 |
|
No problem! You can always view tentative release dates here https://github.com/spring-cloud/spring-cloud-release/milestones |
|
Hi everyone, I have the same error: using the following dependencies: <dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-kubernetes-fabric8</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-kubernetes-fabric8-config</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-kubernetes-fabric8-loadbalancer</artifactId>
</dependency>with spring boot I am using fabric8, but I guess it doesn't matter. There are no newer spring cloud releases. It is supposed to be fixed? |
|
@davgia can you open a new bug and provide a sample, just like the initial one in this thread? then I can take a look at it. thank you |
Hi, i know this is more for issue or feature than help wanted
We recenlty try to migrate from spring boot 2.6.6 to 3.2.5 (yeah big jump)
Our apps running on kubernetes and are package without any application.[yml|yaml|properties]
At startup it picks up the configMap base on the SPRING_APPLICATION_NAME, it's the bootstrap way which is now deprecated (at least legacy and no more the default).
To keep this behaviour we use (with bootstrap false)
SPRING_CONFIG_IMPORT = kubernetes:We are using the
Keeping this deps giving us this error
Switching to
Works as expected
And we can't figure out why
Any ideas ? :(
The text was updated successfully, but these errors were encountered: