jgroups-extras/jgroups-kubernetes

If the KUBERNETES_NAMESPACE is not set the default value is the "default" namespace

spolti opened this issue · 9 comments

spolti commented

If no namespace is set it defaults to the "default" ocp namespace which will case the warn as described in the log message below:

WARN [org.jgroups.protocols.kubernetes.KUBE_PING] (thread-9,ee,hdm78-kieserver-1-nggcf) failed getting JSON response from Kubernetes Client[masterUrl=https://172.30.0.1:443/api/v1, headers={Authorization=#MASKED:937#}, connectTimeout=5000, readTimeout=30000, operationAttempts=3, operationSleep=1000, streamProvider=org.jgroups.protocols.kubernetes.stream.TokenStreamProvider@69991c01] for cluster [ee], namespace [default], labels [null]; encountered [java.lang.Exception: 3 attempt(s) with a 1000ms sleep to execute [OpenStream] failed. Last failure was [java.io.IOException: Server returned HTTP response code: 403 for URL: https://172.30.0.1:443/api/v1/namespaces/default/pods]]

IMHO the default namespace should not be used in this case since this namespace should not be used to deploy applications.

If the namespace is not set it means that we do not want to enable the clustering feature, as the namespace is set if the namespace is not set, this condition [1] is not satisfied and the configuration will proceed.

Another problem found in the tests is that, if we do set the KUBERNETES_NAMESPACE with no value, it will detect that the env has an value and will try to use a blank namespace:

failed getting JSON response from Kubernetes Client[masterUrl=https://172.30.0.1:443/api/v1 , headers={Authorization=#MASKED:874#}, connectTimeout=5000, readTimeout=30000, operationAttempts=3, operationSleep=1000, streamProvider=org.jgroups.protocols.kubernetes.stream.TokenStreamProvider@17978314] for cluster [ee], namespace [], labels [null]; encountered [java.lang.Exception: 3 attempt(s) with a 1000ms sleep to execute [OpenStream] failed. Last failure was [java.io.IOException: Server returned HTTP response code: 403 for URL: https://172.30.0.1:443/api/v1/pods ]]

[1] - https://github.com/jgroups-extras/jgroups-kubernetes/blob/master/src/main/java/org/jgroups/protocols/kubernetes/KUBE_PING.java#L145

rhusar commented

If the namespace is not set it means that we do not want to enable the clustering feature

That does not make sense. You configured a discovery protocol to discover members. If you do not want that, then do not configure a discovery protocol.

  • 👍2
rhusar commented

@spolti Any comment or can we close this?

jfdenise commented

@rhusar , I would vote for reverting this change: 7d7b675
Having the discovery protocol disabled when no namespace env variable has been set would be the expected behavior. "default" namespace is not a namespace advised to use to deploy applications.

belaban commented

I disagree with @jfdenise. Reverting the change would not mean that clustering is disabled, but instead we have a fully configured clustering stack, but discovery will never detect any other members!
This is weird at best, because - if we don't want clustering - we should pick a stack (e.g. in Infinispan) which does not cluster, ie. a single-node, non-replicated, stack!

If people feel strongly about this, then what we could do is

  • Log a warning when namespace is null or "default"
  • Throw an exception instead; this would prevent the stack/pod to start
belaban commented

Any comments? Can we close this issue?

jfdenise commented

@belaban , I am fine with closing it. I better understand the issue. No clustering means a complete different server configuration, not a discovery discovering nothing.

belaban commented

+1