Bug 1746377 - There should be more index pattern in kibana
Summary: There should be more index pattern in kibana
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Logging
Version: 3.11.0
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: ---
: 4.2.0
Assignee: Jeff Cantrill
QA Contact: Anping Li
URL:
Whiteboard:
: 1749782 (view as bug list)
Depends On:
Blocks: 1752850 1752853
TreeView+ depends on / blocked
 
Reported: 2019-08-28 10:08 UTC by Anping Li
Modified: 2019-10-16 06:40 UTC (History)
17 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1752850 (view as bug list)
Environment:
Last Closed: 2019-10-16 06:38:14 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
kibana snapshot (43.75 KB, image/png)
2019-08-28 10:09 UTC, Anping Li
no flags Details
the content of kibana index (94.90 KB, text/plain)
2019-08-28 10:11 UTC, Anping Li
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Github fabric8io openshift-elasticsearch-plugin pull 188 0 'None' closed Bug 1746377: Fetch indices instead of search to seed index patterns 2021-01-22 02:28:29 UTC
Github openshift origin-aggregated-logging pull 1754 0 'None' closed Bug 1746377: Seed index patterns based on match to existing indices 2021-01-22 02:28:29 UTC
Red Hat Product Errata RHBA-2019:2922 0 None None None 2019-10-16 06:40:23 UTC

Description Anping Li 2019-08-28 10:08:36 UTC
Description of problem:
The user 'anli1' own two projects 'logjson1' and 'loggen1'. But the user only show index project.loggen1.**** in kibana. (See the snapshot)


Version-Release number of selected component (if applicable):
openshift3/ose-logging-kibana5:v3.11.141
openshift3/oauth-proxy:v3.11.141

How reproducible:
Always

1. Deploy logging 
openshift_logging_install_eventrouter=true
openshift_logging_es_allow_external=True
openshift_logging_elasticsearch_storage_type=pvc
openshift_logging_es_pvc_storage_class_name=bogus-glusterfs
openshift_logging_es_pvc_dynamic=true
openshift_logging_es_number_of_shards=1
openshift_logging_es_number_of_replicas=1
openshift_logging_es_memory_limit=2Gi
openshift_logging_es_cluster_size=2
openshift_logging_es_nodeselector={"role":"node"}
openshift_logging_namespace=openshift-logging
openshift_logging_install_logging=true

2. user 'anli1' create two projects
oc new-project loggen1
oc new-app https://raw.githubusercontent.com/openshift-qe/v3-testfiles/master/logging/loggen/container_log_template.json
oc new-project logjson1
oc new-app https://raw.githubusercontent.com/openshift-qe/v3-testfiles/master/logging/loggen/container_log_template.json

3. $ oc get projects
NAME       DISPLAY NAME   STATUS
loggen1                   Active
logjson1                  Active

4. check the indices and alias
+ oc exec -c elasticsearch logging-es-data-master-67u8p4ld-1-k95hm -- es_util '--query=_aliases?pretty'

5. View indices on kibana using 'anli1'.  
See the snapshot


Actual results:
The user 'anli1' can only view project.loggen1.******

Expected results: 
The user 'anli1' can view patten '.all', 'project.loggen1.*****' and 'project.logjson1.****'

Comment 1 Anping Li 2019-08-28 10:09:38 UTC
Created attachment 1608941 [details]
kibana snapshot

Comment 2 Anping Li 2019-08-28 10:11:32 UTC
Created attachment 1608954 [details]
the content of kibana index

Comment 4 Jeff Cantrill 2019-08-28 19:46:25 UTC
Please confirm that both namespaces have pods that are generating logs and these are indexed in elasticsearch.  Index patterns are only seeded if data exists in an index that corresponds to a namespace that has pods producing logs.

Comment 7 Jeff Cantrill 2019-09-11 20:25:10 UTC
*** Bug 1749782 has been marked as a duplicate of this bug. ***

Comment 10 Brenton Leanhardt 2019-09-13 14:10:49 UTC

*** This bug has been marked as a duplicate of bug 1746482 ***

Comment 11 Jeff Cantrill 2019-09-13 19:42:05 UTC
Reopening as its not a duplicate.  The other issue was before caching was introduced.  Using the images in question, a given user correctly has permissions to:

developer
  |- indices:
    |-test-a?42a7b97d-d59a-11e9-9649-525400851be1?*/*
    |-test-b?404a9f7c-d59a-11e9-9649-525400851be1?*/*

but they only have one index pattern:

oc exec -c elasticsearch $pod -- es_util --query='.kibana.3dacbce532ccd48f27fa62e993067b3c35f094f7/index-pattern/_search?stored_fields=_id&pretty'
{
  "took" : 0,
  "timed_out" : false,
  "_shards" : {
    "total" : 1,
    "successful" : 1,
    "skipped" : 0,
    "failed" : 0
  },
  "hits" : {
    "total" : 1,
    "max_score" : 1.0,
    "hits" : [
      {
        "_index" : ".kibana.3dacbce532ccd48f27fa62e993067b3c35f094f7",
        "_type" : "index-pattern",
        "_id" : "project.test-a.42a7b97d-d59a-11e9-9649-525400851be1.*",
        "_score" : 1.0
      }
    ]
  }
}

prior to upgrading from v3.11.98 i did see 2 index patterns in Kibana.

I was able to manually create the index pattern using the format of 'project.$ns-name.$ns-uid.*' from the Management tab

Comment 12 Jeff Cantrill 2019-09-13 20:45:37 UTC
This issue is because of a bug in how we try to determine projects that have corresponding indices: KibanaSeed#195.  It is using an msearch incorrectly which is returning the first 1000 entries from only one index and is completely missing any other projects.

The only workaround at the moment is to manually create the index pattern for those which are missing through the Management tab.

Comment 17 Jeff Cantrill 2019-09-17 19:30:37 UTC
(In reply to Jatan Malde from comment #14)

> But I could also see that a normal user who has only view only access on the
> project was able to create the index-pattern from the kibanaUI using the
> Management tab. 

Kibana is likely configure for unique index for non-admin users which means "Management" changes only affect their index.  This is expected.

> 
> So I wish your help to know if this is expected behavior or there are
> certain access level above which only the index-pattern could be created.
> Also are the OCP RBAC not used while managing the user privileges on
> kibanaUI. 
> 

See https://bugzilla.redhat.com/show_bug.cgi?id=1746482#c21

Comment 18 Jeff Cantrill 2019-09-17 19:32:18 UTC
(In reply to Roberto from comment #15)

> THe CU followed the workaround without success, it made no difference to log
> in with a user that has admin to the project the user would like to access
> log files through Kibana for.
> 
> The user is still not able to change the wrong pre-selected index.
> 
Please identify the version of the images being used in your specific customer case.

Comment 20 Roberto 2019-09-18 09:01:52 UTC
(In reply to Jeff Cantrill from comment #18)
> (In reply to Roberto from comment #15)
> 
> > THe CU followed the workaround without success, it made no difference to log
> > in with a user that has admin to the project the user would like to access
> > log files through Kibana for.
> > 
> > The user is still not able to change the wrong pre-selected index.
> > 
> Please identify the version of the images being used in your specific
> customer case.

Hi, 
In this case, they have v3.11.129

Comment 22 Anping Li 2019-09-18 10:27:54 UTC
The pattern include user's all projects using  openshift/ose-logging-kibana5/images/v4.2.0-201909162219

Comment 29 errata-xmlrpc 2019-10-16 06:38:14 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, 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-2019:2922


Note You need to log in before you can comment on or make changes to this bug.