search

crate / helm-charts

Helm charts for Kubernetes
5 stars 3 forks source link

4.0.4 (4.0.10) wrong options #4

Open masterkain opened 4 years ago

masterkain commented 4 years ago

I tried to run this chart but ultimately failed.

https://github.com/crate/helm-charts/blob/master/src/crate/templates/statefulset.yaml#L38-L39

- -Clicense.enterprise=false I think it needs to be removed

- -Cdiscovery.srv.query=_{{ include "crate.clusterName" . }}._tcp.{{ .Values.service.name }}.{{ .Release.Namespace }}.svc.cluster.local

the official doc https://crate.io/docs/crate/guide/en/latest/deployment/containers/kubernetes.html reports it might be: - -Cdiscovery.srv.query=_crate-internal._tcp.crate-internal-service.${NAMESPACE}.svc.cluster.local

I had issues with the parameter srv.query shipped with this chart as the name once deployed would not resolve.

once I solved these issues I tried with both 4.0.4 and 4.0.10 images but the cluster was really unstable, either with gp2 or efs as storageClass, pod crashing I think due to name resolution of something or failure to elect masters.

mfussenegger commented 4 years ago
  • -Clicense.enterprise=false I think it needs to be removed

Yes you're right. Would you like to create a PR to drop it?

@OJFord do you have any input on the second part of the issue?

OJFord commented 4 years ago

Hi, I'm sorry for the delay.

I had issues with the parameter srv.query shipped with this chart as the name once deployed would not resolve.

That looks the same as the docs link suggests, modulo the values given in your values.yaml. Presently, crate.clusterName provides the value of the same key in values.yaml if set (null by default), or otherwise the value of app (crate by default), and service.name is also crate by default.

I'm surprised if the specific values matter; I had thought that the name (_crate vs. _crate-internal at the beginning, without the _) simply needed to match the name given in the other option (which we ensure it does whatever the values.yaml, by using the same include "crate.clusterName"), and the srv.query just needed to be the same across each replica. But you've found that that's not the case, and that the -internal suffix is significant?

the cluster was really unstable, either with gp2 or efs as storageClass, pod crashing I think due to name resolution of something or failure to elect masters

I haven't experienced that, do the logs reveal anything useful? (There is usually a bunch of logging around election.)

rjbaat commented 3 years ago

@mfussenegger @OJFord

I tried this chart with the newest 4.5.0 image tag. But I get messages like: 

master not discovered yet, this node has not previously joined a bootstrapped (v4+) cluster, and this node must discover master-eligible nodes [2] to bootstrap a cluster

The 3 individual pods are running oke, but it will not cluster somehow. Maybe it has to do with your previous srv lookup?

Any idea?