Bug 1671226

Summary: Execute es_load_kibana_ui_objects in ES pod failed.
Product: OpenShift Container Platform Reporter: Qiaoling Tang <qitang>
Component: LoggingAssignee: Jeff Cantrill <jcantril>
Status: CLOSED ERRATA QA Contact: Qiaoling Tang <qitang>
Severity: low Docs Contact:
Priority: low    
Version: 4.1.0CC: anli, aos-bugs, dhatchet, dkulkarn, ikarpukh, jcantril, lvlcek, periklis, rmeggins
Target Milestone: ---   
Target Release: 4.6.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: No Doc Update
Doc Text:
undefined
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-10-27 15:09:31 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Qiaoling Tang 2019-01-31 06:56:43 UTC
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:

Comment 1 Qiaoling Tang 2019-01-31 06:58:17 UTC
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

Comment 2 Jeff Cantrill 2019-02-01 10:10:42 UTC
It is necessary to log into Kibana to allow that workflow to seed your kibana index prior to execution of this script.

Comment 3 Qiaoling Tang 2019-02-02 01:41:26 UTC
I've logged into kibana before I executing the command, but there is no .kibana.* index in ES pod.

Comment 4 Qiaoling Tang 2019-02-02 01:52:33 UTC
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.

Comment 5 Jeff Cantrill 2019-02-05 19:58:28 UTC
(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/

Comment 6 Jeff Cantrill 2019-03-08 14:39:39 UTC
*** Bug 1686677 has been marked as a duplicate of this bug. ***

Comment 8 damo 2020-03-12 03:33:46 UTC
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

Comment 9 Jeff Cantrill 2020-04-28 00:00:41 UTC
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

Comment 11 Jeff Cantrill 2020-06-03 16:33:58 UTC
Moving to 4.6 but we should fix in a 4.5.z stream

Comment 13 Periklis Tsirakidis 2020-07-08 08:18:56 UTC
Put UpcomingSprint label, fix not going to land early enough by EUS.

Comment 16 Jeff Cantrill 2020-08-05 18:58:14 UTC
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

Comment 20 Qiaoling Tang 2020-08-18 02:13:07 UTC
Tested with elasticsearch-operator.4.6.0-202008141222.p0, the command `es_load_kibana_ui_objects` is removed.

Comment 22 errata-xmlrpc 2020-10-27 15:09:31 UTC
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

Comment 23 Red Hat Bugzilla 2023-09-18 00:15:25 UTC
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 120 days