Description of problem: Add kibana dashboards for cluster-admin user using `es_load_kibana_ui_objects <cluster-admin-user>` command in ES pod failed. Give user qitang cluster-admin role, then execute `es_load_kibana_ui_objects <cluster-admin-user>` command in ES pod: $ oc exec elasticsearch-clientdatamaster-0-1-5d48cf88c7-r8xsx -- es_load_kibana_ui_objects qitang [2019-01-31 06:38:59,544][ERROR][container.run ] Could not find kibana index .kibana.c12936f199296e4d3077f69d6ef20d7620236afc for user qitang: 404 command terminated with exit code 1 Version-Release number of selected component (if applicable): $ oc get clusterversion NAME VERSION AVAILABLE PROGRESSING SINCE STATUS version 4.0.0-0.nightly-2019-01-30-145955 True False 58m Cluster version is 4.0.0-0.nightly-2019-01-30-145955 quay.io/openshift/origin-logging-elasticsearch5@sha256:0c20bbd81be621779d81bb02eb9621019ddab365c53d89d6a3f47d222f4beda6 How reproducible: Always Steps to Reproduce: 1.Deploy logging 2.create an user with cluster-admin role 3.execute `oc exec $ES_pod -- es_load_kibana_ui_objects <username>` Actual results: create kibana dashboards failed Expected results: Additional info:
Indices in ES pod: $ oc exec elasticsearch-clientdatamaster-0-1-5d48cf88c7-r8xsx -- indices Thu Jan 31 06:57:30 UTC 2019 health status index uuid pri rep docs.count docs.deleted store.size pri.store.size green open .searchguard SIY4tw9TS8ilJYkHO4OhXg 1 1 5 0 0 0 green open .operations.2019.01.31 A3o_-gXHSTqS-C5sx8dUgg 3 1 261913 0 438 218 green open project.test1.b30cca4d-2521-11e9-882c-0ae9db62b038.2019.01.31 D0D-qkmZSx6lcsiKWbSIDQ 3 1 1583 0 5 1 green open .kibana ZgoUDR4bSmKbVX3P8EDsVg 1 1 5 0 0 0
It is necessary to log into Kibana to allow that workflow to seed your kibana index prior to execution of this script.
I've logged into kibana before I executing the command, but there is no .kibana.* index in ES pod.
When log into kibana with normal user, there will create a .kibana.* index in ES, when log into kibana with cluster-admin, there won't create a .kibana.* index in ES.
(In reply to Qiaoling Tang from comment #4) > When log into kibana with normal user, there will create a .kibana.* index > in ES, when log into kibana with cluster-admin, there won't create a > .kibana.* index in ES. Lowering the priority as this is really an enhancement. It manifests itself because we modified the kibana index mode to be 'shared_ops' in 4.0. The script assumes it will generate the proper index for any user name given, but admin users share the Kibana index so it is always '.kibana'. One could argue this script is only intended to be used for unique kibana profiles. Lowering the priority for now. [1] https://github.com/openshift/elasticsearch-operator/pull/56/
*** Bug 1686677 has been marked as a duplicate of this bug. ***
I have found that argument <cluster-admin-user> needs to be in uppercase, ie es_load_kibana_ui_objects myid >>> no match es_load_kibana_ui_objects MYID >>> match
Bumping the priority and modifying the target release to 4.5 since it looks like the objects are possibly broken against the new indexmanagement and use of OpenDistro. @Lukas, reassigning to you to review and determine if it makes sense to fix these scripts in the new data model
Moving to 4.6 but we should fix in a 4.5.z stream
Put UpcomingSprint label, fix not going to land early enough by EUS.
These utilities are removed from the image since they are no longer documented or supported. We prefer to encourage users to take advantage of the visualizations provided by the console
Tested with elasticsearch-operator.4.6.0-202008141222.p0, the command `es_load_kibana_ui_objects` is removed.
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 (OpenShift Container Platform 4.6.1 extras update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2020:4198
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 120 days