Image version: registry.ops.openshift.com/openshift3/logging-elasticsearch:v220.127.116.11.21
[root@yocum-test-5-master-151b5 ~]# oc logs -f logging-es-s6yxhcz4-3-rvq96
[2017-10-18 10:46:16,055][INFO ][container.run ] Begin Elasticsearch startup script
[2017-10-18 10:46:16,066][INFO ][container.run ] Comparing the specified RAM to the maximum recommended for Elasticsearch...
[2017-10-18 10:46:16,067][INFO ][container.run ] Inspecting the maximum RAM available...
[2017-10-18 10:46:16,070][INFO ][container.run ] ES_HEAP_SIZE: '5632m'
[2017-10-18 10:46:16,072][INFO ][container.run ] Setting heap dump location /elasticsearch/persistent/heapdump.hprof
[2017-10-18 10:46:16,074][INFO ][container.run ] Checking if Elasticsearch is ready on https://localhost:9200
Exception in thread "main" java.lang.IllegalArgumentException: Unknown Discovery type [kubernetes]
Refer to the log for complete error details.
I know you responded in the email but can you provide information here. Is this a result of new images being pulled without being officially deployed via ansible? Is there some other scenario that can lead us to this situation?
This occurs when trying to deploy outdated ES image with the newest ansible (after label discovery and readiness probe were merged). At the time of writing, there are still a couple of images in our registries, that deserve a rebuild. The label discovery and readiness probe were merged in the second half of September and it should be contained in 3.6 and will be contained in 3.7 once released.
Here 3.6 tag and latest have not been rebuilt in two months
Here latest contains the proper library but 3.6 lacks update for three months
A fast fix could be either to get ES image built after mid-September when the feature was merged or remove readiness probe from ES.
If the openshift-ansible logging tasks are designed to work with a certain version of the logging images, why aren't those tasks requiring that minimum version be used?
I am not sure how to require 3.6 image built after mid-September. Readiness probe was requested to be backported to 3.6 but images containing this functionality weren't rebuilt yet.
*** Bug 1505860 has been marked as a duplicate of this bug. ***
While it is certainly good to make a short-term release to address this problem, the long term problem is that for any number of valid reasons, the openshift-ansible playbooks can be told to install using a version of OpenShift for which those playbooks are not compatible. This fact appears to be the core problem.
We need to engineer a way for the playbooks and images to work together to avoid these kinds of problems. Please find a way to track this need via another BZ, an upstream issue in the repos, or Trello card.
From test result, the readiness will not be added to ES.
The following scenarios pass:
1) openshift-ansible:v18.104.22.168.49 deploy v22.214.171.124.5
2) openshift-ansible:v126.96.36.199.49 deploy v188.8.131.52.49
3) openshift-ansible:v184.108.40.206.49 upgrade logging from 3.5.0 to v220.127.116.11.49.
4) openshift-ansible:v18.104.22.168.49 upgrade logging from the current latest release images ( v22.214.171.124.5: elasticsearch, v126.96.36.199.21: fluentd/kibana/auth-proxy) to v188.8.131.52.49.
Please ignore the comment 9, I used the image openshift3/ose-ansible:v184.108.40.206.49. I found the openshift3/ose-ansible:v220.127.116.11.49 is built with openshift-ansile-v18.104.22.168.5.
The following scenario pass testing with openshift-ansible-v22.214.171.124.59. so move bug to verified.
Deploy Logging v126.96.36.199.49 on OCP v188.8.131.52.49
Upgrade Logging 3.5.0 deployed by openshift-ansile-3.5.132 to OCP v184.108.40.206.49 on OCP v220.127.116.11.49
By the way, If you want to deploy Elasticsearch:v18.104.22.168.5, you must use openshift-ansible-22.214.171.124 and prior.
this will provide partial solution, until we have a better way
Relevant information on how to revert the discovery mechanism or disable the probe:
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.