Replies: 2 comments · 11 replies
-
Seems to work fine for me locally as well as pass in the tests. You should probably:
|
Beta Was this translation helpful? Give feedback.
All reactions
-
fixed the logs format, and here's the kafka cluster spec:
|
Beta Was this translation helpful? Give feedback.
All reactions
-
I don't think the log is complete - it normally starts by printing configurations and explaining what it is doing. |
Beta Was this translation helpful? Give feedback.
All reactions
-
That said, the Kafka resource (with the only modification of removing the resources) seems to work fine for me:
|
Beta Was this translation helpful? Give feedback.
All reactions
-
Wait ... I see now that your log is mixed up and is in the wrong order. I think there is some issue with how it works on your networking stack. I guess you have some dual stack networking that causes this:
Maybe that causes the problem? |
Beta Was this translation helpful? Give feedback.
All reactions
-
the pod is in a crashloopbackoff heres all the logs between the crash error (with a bit of overlap):
|
Beta Was this translation helpful? Give feedback.
All reactions
-
is there anyway i can overwrite the startup script so i can better debug it? |
Beta Was this translation helpful? Give feedback.
All reactions
-
yes, its deployed to a gke cluster with dual stack enabled |
Beta Was this translation helpful? Give feedback.
All reactions
-
trying a single stack cluster now |
Beta Was this translation helpful? Give feedback.
All reactions
-
yup, it does seem to work fine on single stack, but i really prefer to have it on the dual stack cluster |
Beta Was this translation helpful? Give feedback.
All reactions
-
im going to try to force ipv4 here strimzi-kafka-operator/docker-images/kafka-based/kafka/scripts/set_kafka_jmx_options.sh Line 9 in 97d4659
by using |
Beta Was this translation helpful? Give feedback.
All reactions
-
this worked, thanks for your help. |
Beta Was this translation helpful? Give feedback.
All reactions
This discussion was converted from issue #9947 on April 11, 2024 09:03.
-
Bug Description
when trying to enable JMX without a passwork, kafka is still trying to load a password file, that doesnt exists
Steps to reproduce
create a kafka cluster with a open jmx port:
Expected behavior
the server should start with an unprotected jmx port
Strimzi version
0.40.0
Kubernetes version
1.27.8-gke.1067004
Installation method
yaml files
Infrastructure
No response
Configuration files and logs
Additional context
No response
Beta Was this translation helpful? Give feedback.
All reactions