Red Hat Bugzilla – Bug 1253726
[DOCS] Provide details about EAP6 clustering
Last modified: 2017-07-04 02:05:16 EDT
Section Number and Name:
No section. I'm suggesting a new one.
Describe the issue:
Provide details about how EAP 6 clustering works in v3 as well provide ways to test if clustering is working.
Suggestions for improvement:
Can you please give us the detailed steps for clustering using xpaas images like EAP 6 ?
I came across http://ce-docs.usersys.redhat.com/openshift/eap/6.4/clustering.html where the first and the second point consists of "(see table above)" but the table with values for OPENSHIFT_KUBE_PING_NAMESPACE and OPENSHIFT_KUBE_PING_LABELS is missing.
Thanks and regards,
(In reply to Miheer Salunke from comment #12)
> Hi Kevin,
> Can you please give us the detailed steps for clustering using xpaas images
> like EAP 6 ?
> I came across
> http://ce-docs.usersys.redhat.com/openshift/eap/6.4/clustering.html where
> the first and the second point consists of "(see table above)" but the table
> with values for OPENSHIFT_KUBE_PING_NAMESPACE and OPENSHIFT_KUBE_PING_LABELS
> is missing.
> Thanks and regards,
> Miheer Salunke
I think the default clustering for EAP 6.4 (with 3.1 xPaaS images) uses the kube ping clustering model, and does so be default.
However your request miheer brings up a good point about why the information in http://ce-docs.usersys.redhat.com/openshift/eap/6/clustering.html is not part of the public docs. Adding Vikrim for clarification and privatization!
A potential suggestion for these docs: the OPENSHIFT_KUBE_PING_NAMESPACE env var sounds like a good candidate to be populated using the downward API:
I believe that in the typical use case you would be clustering with pods in the same namespace, so adding something like this to the deployment config should populate that env var automatically for this use case:
- name: OPENSHIFT_KUBE_PING_NAMESPACE
Doing the same automagically for OPENSHIFT_KUBE_PING_LABELS is a bit more tricky because you can't use the env-based downward API (only static metadata can be referenced that way)
Can we add some additional information into section 3.2  covering clustering with the xPaaS EAP image?
Might be good to provide example values for the environment variables:
Also, an example CLI setting the environment variable in a deployment config:
oc env dc/my-test-app -e OPENSHIFT_KUBE_PING_NAMESPACE=project_name
Also the text "Example 3.1. Policy commands" should be "Example 3.2.1. Policy commands".
Thanks for the suggestions everyone.
I've updated the xPaaS content to include the examples provided by Travis, and cleaned it up the topic somewhat to make it
The testing of clustering is more complex so I've cloned this bug (BZ#1376871) to track that aspect, and so that doesn't impede publication of the examples.
Travis - can you review Andrew's changes  for KUBE_PING? If they are ok, I will go ahead and publish.
Moving this bug to ON_QA.
One suggestion from me:
Would be nice to provide some kind of verification of clustering (KUBE_PING) to users. For example, if clustering is enabled, one can see the following logs from within a pod:
"Service account has sufficient permissions to view pods in kubernetes (HTTP 200). Clustering will be available."
"05:00:24,017 INFO [org.jgroups.protocols.openshift.KUBE_PING] (MSC service thread 1-7) namespace [rkoubsky] set; clustering enabled"
The following part of the documentation is lacking some information:
"The OPENSHIFT_KUBE_PING_LABELS environment variables should be set. If not set, pods outside of your application (albeit in your namespace) will try to join.
This should make clearer that the label should match what has been set at the service level. Also "oc new-app" with later versions of OpenShift default to app=<app_name> and not application=<app_name>
This update has been published and is available on the Portal: