Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.

Bug 1511432

Summary: [3.7.0]some indices name miss in kibana
Product: OpenShift Container Platform Reporter: Anping Li <anli>
Component: LoggingAssignee: Rich Megginson <rmeggins>
Status: CLOSED ERRATA QA Contact: Anping Li <anli>
Severity: high Docs Contact:
Priority: unspecified    
Version: 3.7.0CC: aos-bugs, bkozdemb, jcantril, juzhao, pweil, rmeggins, smunilla, stwalter, wsun
Target Milestone: ---Keywords: Regression
Target Release: 3.7.z   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Cause: The multi tenancy plugin in Elasticsearch was inadvertently changed, while fixing another bug, not to look up projects for the user upon every login. Consequence: The list of projects was not displayed properly. Fix: The multi tenancy plugin in Elasticsearch was changed back to look up projects for the user upon every login Result: The list of projects is displayed properly.
Story Points: ---
Clone Of:
: 1512495 1530866 (view as bug list) Environment:
Last Closed: 2018-04-05 09:30:40 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On:    
Bug Blocks: 1512495, 1530866    
Attachments:
Description Flags
Snapshot 1
none
video to show how to select, and remove, a namespace
none
project indices could be found on kibana UI. none

Description Anping Li 2017-11-09 10:47:43 UTC
Created attachment 1349850 [details]
Snapshot 1

Description of problem:
some indices (anli2project,anliprj and etc) couldn't be list in kibana (Snapshot 1).  while the other indices (.operations.* wzheng1.* openshift-ansible-service-broker and openshift-template-service-broker)  can be list.  I can retrieved document from  indices anli2project and anliprj in kibana (snapshot 1)
  

Version-Release number of selected component (if applicable):
OCP v3.7.4-1
logging: v3.7.4-1



How reproducible:
always

Steps to Reproduce:
1) deploy logging 
2) Create somes applications and drop some applications.
3) View indices on kibana


Some indices can not be list in kibana

Expected results:
All indices can be displayed in kibana.


Additional info:


1) oc get projects
NAME                                DISPLAY NAME   STATUS
9ornk                                              Active
anli2project                                       Active
anliprj                                            Active
default                                            Active
gl6cp                                              Terminating
hasha-pro1                                         Active
install-test                                       Active
kube-public                                        Active
kube-service-catalog                               Active
kube-system                                        Active
logging                                            Active
m0kit                                              Active
management-infra                                   Active
openshift                                          Active
openshift-ansible-service-broker                   Active
openshift-infra                                    Active
openshift-node                                     Active
openshift-template-service-broker                  Active
wzheng1                                            Active


3) indices list:

.kibana
.kibana.0b4f1ae0822e2a54b3a7b5dd659ee89bdcb2925b
.kibana.6169e9a14489a4f2123370a52f6dcde354adda4e
.kibana.b001ec4ba8290276aa0cad70c7b6afe4d07077cd
.operations.2017.11.09
.searchguard.logging-es-data-master-sewcb10r
fluentd
project.07eqx.cf66c6f1-c527-11e7-95bb-fa163eb823db.2017.11.09
project.0gcnt.bf6e6d25-c52a-11e7-bf5d-fa163e612505.2017.11.09
project.0o4q0.d1d2ffdc-c527-11e7-95bb-fa163eb823db.2017.11.09
project.0rkt9.d1d52ade-c529-11e7-95bb-fa163eb823db.2017.11.09
project.1-wyq.392295b4-c529-11e7-95bb-fa163eb823db.2017.11.09
project.12x0f.261cf99a-c52a-11e7-95bb-fa163eb823db.2017.11.09
project.1nt1v.7b835530-c527-11e7-95bb-fa163eb823db.2017.11.09
project.21ybt.434dc005-c526-11e7-95bb-fa163eb823db.2017.11.09
project.2o180.b806848f-c526-11e7-95bb-fa163eb823db.2017.11.09
project.3ggms.ff04d622-c527-11e7-95bb-fa163eb823db.2017.11.09
project.4-in4.165f97b0-c529-11e7-95bb-fa163eb823db.2017.11.09
project.5apij.15b2642d-c528-11e7-95bb-fa163eb823db.2017.11.09
project.5gwe5.977b18b8-c528-11e7-95bb-fa163eb823db.2017.11.09
project.5uhbh.d6957d6a-c527-11e7-95bb-fa163eb823db.2017.11.09
project.5zqrt.d904596d-c528-11e7-bf5d-fa163e612505.2017.11.09
project.6-1g1.39fcdea6-c526-11e7-95bb-fa163eb823db.2017.11.09
project.67c3v.ff04708a-c527-11e7-95bb-fa163eb823db.2017.11.09
project.6eajd.b89bde04-c528-11e7-95bb-fa163eb823db.2017.11.09
project.6zpvq.77548a34-c528-11e7-bf5d-fa163e612505.2017.11.09
project.8-h60.d03a6744-c528-11e7-95bb-fa163eb823db.2017.11.09
project.9ornk.9be07fd2-c52a-11e7-95bb-fa163eb823db.2017.11.09
project.9yz78.27922c73-c526-11e7-95bb-fa163eb823db.2017.11.09
project.anli2project.abc34861-c528-11e7-9014-fa163e9637ef.2017.11.09
project.anliprj.f4c09883-c524-11e7-9014-fa163e9637ef.2017.11.09
project.bc2e9.e12518d0-c527-11e7-95bb-fa163eb823db.2017.11.09
project.ci2l2.71e7a51f-c527-11e7-95bb-fa163eb823db.2017.11.09
project.cie8a.918b0d28-c525-11e7-95bb-fa163eb823db.2017.11.09
project.ckt8a.9fe632a3-c527-11e7-95bb-fa163eb823db.2017.11.09
project.ddofo.af7e0855-c527-11e7-95bb-fa163eb823db.2017.11.09
project.e5b25.22972a76-c529-11e7-95bb-fa163eb823db.2017.11.09
project.fu92u.a7455d0c-c529-11e7-bf5d-fa163e612505.2017.11.09
project.gbb-u.26031b69-c529-11e7-bf5d-fa163e612505.2017.11.09
project.gi7z7.c6479804-c527-11e7-95bb-fa163eb823db.2017.11.09
project.gl6cp.1beb6e5d-c52b-11e7-a622-fa163e612505.2017.11.09
project.goxjq.11f6f555-c529-11e7-95bb-fa163eb823db.2017.11.09
project.hasha-pro1.6aaec4e7-c521-11e7-86a1-fa163e612505.2017.11.09
project.hgnny.abb81ffb-c527-11e7-95bb-fa163eb823db.2017.11.09
project.hr7ep.509a79ff-c526-11e7-95bb-fa163eb823db.2017.11.09
project.install-test.9880e212-c505-11e7-9014-fa163e9637ef.2017.11.09
project.iyd9d.e384163e-c526-11e7-95bb-fa163eb823db.2017.11.09
project.j4jm1.afe8b39d-c528-11e7-95bb-fa163eb823db.2017.11.09
project.kube-service-catalog.4fe3a64a-c505-11e7-9014-fa163e9637ef.2017.11.09
project.lmcd2.3339720e-c529-11e7-95bb-fa163eb823db.2017.11.09
project.logging.e59b8853-c504-11e7-9014-fa163e9637ef.2017.11.09
project.loj5c.aa823657-c528-11e7-bf5d-fa163e612505.2017.11.09
project.lwjr1.dd458993-c529-11e7-95bb-fa163eb823db.2017.11.09
project.m0kit.07e19e81-c52b-11e7-95bb-fa163eb823db.2017.11.09
project.n2ca3.8fcfbc01-c529-11e7-95bb-fa163eb823db.2017.11.09
project.openshift-ansible-service-broker.79964ba6-c505-11e7-9014-fa163e9637ef.2017.11.09
project.openshift-template-service-broker.8494d213-c505-11e7-9014-fa163e9637ef.2017.11.09
project.pct1w.5e8f0a7a-c528-11e7-95bb-fa163eb823db.2017.11.09
project.pmn0g.e4a71bf4-c527-11e7-95bb-fa163eb823db.2017.11.09
project.pztft.d382be8d-c525-11e7-95bb-fa163eb823db.2017.11.09
project.r382k.ad95be00-c528-11e7-95bb-fa163eb823db.2017.11.09
project.rbtpj.7b835172-c527-11e7-95bb-fa163eb823db.2017.11.09
project.rbxse.e524ef59-c528-11e7-95bb-fa163eb823db.2017.11.09
project.rlmys.3b141df6-c525-11e7-95bb-fa163eb823db.2017.11.09
project.rnucm.c1a6bfa1-c527-11e7-95bb-fa163eb823db.2017.11.09
project.sxfom.f8addc18-c525-11e7-95bb-fa163eb823db.2017.11.09
project.t-e-9.ed3cf0aa-c526-11e7-95bb-fa163eb823db.2017.11.09
project.te2xa.eadc066e-c529-11e7-95bb-fa163eb823db.2017.11.09
project.u-oef.fb52e7fa-c526-11e7-95bb-fa163eb823db.2017.11.09
project.vrkam.8774d2cc-c529-11e7-95bb-fa163eb823db.2017.11.09
project.wzheng1.48713d10-c528-11e7-b38d-fa163e612505.2017.11.09
project.yeqhp.569cb487-c528-11e7-95bb-fa163eb823db.2017.11.09
project.z4tca.3784f82f-c52a-11e7-95bb-fa163eb823db.2017.11.09
project.zwulx.0f93e476-c52a-11e7-95bb-fa163eb823db.2017.11.09

3) sh-4.2$ curl -s -XGET --cacert /etc/elasticsearch/secret/admin-ca --cert /etc/elasticsearch/secret/admin-cert --key /etc/elasticsearch/secret/admin-key 'https://localhost:9200/project.anli2project*/_search?pretty&size=50&q=hostname:*' --insecure | python -c "import sys, json; print json.load(sys.stdin)['hits']['total']"
295

Comment 2 Jeff Cantrill 2017-11-09 15:44:18 UTC
This is a timing issue where the index-mappings are not corrected until the cache expires which occurs every minute.  After expiration, and possibly refreshing the browser, you should see the new index mappings.

Comment 3 Junqi Zhao 2017-11-10 06:36:12 UTC
Tested on free-stg cluster, created one project and waited for a long time, project index showed on kibana but disppeared soon, then it can not be found on kibana.

Image version is the same with this defect.

We don't have this issue a few days ago.

Comment 4 Anping Li 2017-11-10 08:21:03 UTC
@jeff,  Hit Same error in a new environment with only 4 active projects. I can fetch data via curl command ( Both with cluster-admin and common user). I can list index with logging-curator

1) active projects (default,logging,anlitest,anlitest2)
2) curl -s -vk -H "X-Proxy-Remote-User: anli" -H "Authorization: Bearer GoMZeJrIo1ViauNJ6l0gz7HlMGHlNGatiYIc8lkKsLI" -H "X-Forwarded-For: 127.0.0.1" "https://logging-es.logging.svc:9200/project.anlitest*/_search?q=*" | python -c "import sys, json; print json.load(sys.stdin)['hits']['total']"
1444
3)  curator --host logging-es --use_ssl --certificate /etc/curator/keys/ca --client-cert /etc/curator/keys/cert --client-key /etc/curator/keys/key --loglevel ERROR show indices --all-indices
.kibana
.kibana.d033e22ae348aeb5660fc2140aec35850c4da997
.kibana.dfd6f6b721536c3de0c7718086ac4dd794c102d6
.searchguard.logging-es-data-master-8pbaz9xo
project.anlitest.13b84d89-c507-11e7-9d8a-fa163e78c39e.2017.11.10
project.anlitest2.300a3091-c5df-11e7-88cd-fa163e78c39e.2017.11.10
project.logging.8a782ab7-c471-11e7-bff3-fa163e78c39e.2017.11.10

Comment 6 Anping Li 2017-11-10 08:54:01 UTC
I have waited for one hour and clear everything on Web browsers. the result is same with comment4.

Comment 7 Rich Megginson 2017-11-10 14:40:18 UTC
3) indices list:

...
fluentd

This is bad.  This means the elasticsearch index name creation is having problems.  Sure enough, from the logs:

2017-11-09 03:13:47 -0500 [error]: record cannot use elasticsearch index name type project_full: record is missing kubernetes.namespace_id field: {"docker"=>{"container_id"=>"f9cea645a380ea782d6efdc9ed423059b729c2903f2752519e87ff345f332053"}, "kubernetes"=>{"container_name"=>"caddy-docker-pod", "namespace_name"=>"ilf0m", "pod_name"=>"caddy-docker"}, ...

and

2017-11-09 04:11:39 -0500 [warn]: dump an error event: error_class=TypeError error="no implicit conversion of nil into String" tag="journal.container._openshift_" time=1510218699 record={"PRIORITY"=>"6", "_UID"=>"0", "_GID"=>"0", "_CAP_EFFECTIVE"=>"1fffffffff", "_SYSTEMD_SLICE"=>"system.slice", "_BOOT_ID"=>"a9da6ebbc15e4343a17cd9104a0fc503", "_MACHINE_ID"=>"321923336865459d9c8b86687ba3690d", "_HOSTNAME"=>"host-172-16-120-81", "_TRANSPORT"=>"journal", "_SYSTEMD_CGROUP"=>"/system.slice/docker.service", "_SYSTEMD_UNIT"=>"docker.service", "_SELINUX_CONTEXT"=>"system_u:system_r:container_runtime_t:s0", "_PID"=>"120481", "_COMM"=>"dockerd-current", "_EXE"=>"/usr/bin/dockerd-current", "_CMDLINE"=>"/usr/bin/dockerd-current --add-runtime docker-runc=/usr/libexec/docker/docker-runc-current --default-runtime=docker-runc --authorization-plugin=rhel-push-plugin --exec-opt native.cgroupdriver=systemd --userland-proxy-path=/usr/libexec/docker/docker-proxy-current --selinux-enabled --log-driver=journald --signature-verification=False --storage-driver devicemapper --storage-opt dm.fs=xfs --storage-opt dm.thinpooldev=/dev/mapper/rhel-docker--pool --storage-opt dm.use_deferred_removal=true --storage-opt dm.use_deferred_deletion=true --mtu=1350 --add-registry registry.reg-aws.openshift.com:443 --add-registry registry.access.redhat.com --block-registry registry.hacker.com --insecure-registry brew-pulp-docker01.web.prod.ext.phx2.redhat.com:8888 --insecure-registry virt-openshift-05.lab.eng.nay.redhat.com:5000 --insecure-registry virt-openshift-05.lab.eng.nay.redhat.com:5001 --insecure-registry registry.reg-aws.openshift.com:443 --insecure-registry asb-registry.usersys.redhat.com:5000 --add-registry registry.access.redhat.com", "MESSAGE"=>"---> Installing application source ...", "CONTAINER_ID"=>"5db7208a666e", "CONTAINER_ID_FULL"=>"5db7208a666e7128943803e4c8c6a15d3e3449a0399bf5758ce98c0447d8b75f", "CONTAINER_NAME"=>"s2i_openshift_ruby_20_centos7_sha256_751a3cd1905914389fe568c25b3d5367cd705a0e4f81970a361f670ce891baf7_2563cbd7", "_SOURCE_REALTIME_TIMESTAMP"=>"1510218699134795", "pipeline_metadata"=>{"collector"=>{"ipaddr4"=>"10.2.12.141", "ipaddr6"=>"fe80::858:aff:fe02:c8d", "inputname"=>"fluent-plugin-systemd", "name"=>"fluentd", "received_at"=>"2017-11-09T09:11:39.369525+00:00", "version"=>"0.12.39 1.6.0"}}}

Comment 8 Anping Li 2017-11-10 16:37:06 UTC
There is same issue with latest v3.6 images. atomic-openshift-3.6.173.0.49 and Logging: v3.6.173.0.72

Comment 9 Rich Megginson 2017-11-10 23:46:13 UTC
You can confirm that this is a regression?  This exact same test was run against 3.7.earlier and 3.6.earlier and there were no missing records/indices?  Because if the test creates and deletes namespaces, there should have been missing records/indices with previous releases.

Comment 13 Rich Megginson 2017-11-13 18:24:51 UTC
When I log into Kibana as admin/admin, the first thing I see is that I can only select .all or .operations.*

I go to the Settings tab - Configure an index pattern - specify project.anlitest.* as the pattern.  It does some sort of search, because it thinks for a moment, then displays the Time-field name list with the correct field names in the list.  Select "@timestamp" and press Create.  This gives the following error:

Could not locate that index-pattern (id: project.anlitest.*)

But the index is clearly there:

oc exec -c elasticsearch $espod -- curl -s -k --cert /etc/elasticsearch/secret/admin-cert --key /etc/elasticsearch/secret/admin-key https://localhost:9200/_cat/indices

green open project.anlitest.13b84d89-c507-11e7-9d8a-fa163e78c39e.2017.11.13 1 0  5328 0  1.4mb  1.4mb

Comment 14 Rich Megginson 2017-11-13 19:06:11 UTC
I think what should happen is that there should be an index pattern called "project.*" which lists all of the projects.  That's what I see using the latest 3.7 deployment.  But it still won't let me create a new index pattern e.g. project.logging.*

Comment 15 Rich Megginson 2017-11-13 19:44:09 UTC
Created attachment 1351670 [details]
video to show how to select, and remove, a namespace

I was able to manually create the "project.*" index in the QE lab kibana.

go to the Settings tab - Configure an index pattern - specify project.* as the pattern.  It does some sort of search, because it thinks for a moment, then displays the Time-field name list with the correct field names in the list.  Select "@timestamp" and press Create.

I think the severity of this bug should be decreased.  The workaround is pretty simple.  If you want to see the indices for a specific project, you can select the ".all" index, or use the "project.*" index pattern if it exists.  Then, scroll down to the "kubernetes.namespace_name" field and click on it. It should expand and show all of the namespaces that are included in the time window of the current search (by default, only the last 15 minutes).  Close to, and associated with, each namespace name, there is a magnifying class icon with a "-" and one with a "+".  If you click on the one with the "+" the view will change to show only records from that namespace.  The bar at the top will have that namespace name as the search criteria.  If you mouse over the namespace name in the bar, there will be several icons.  If you click on the trashcan icon, it will remove the namespace and show records from all namespaces again.

I have attached a short video demonstrating this.

I'll need to discuss with Jeff what the intention is of the new Kibana behavior.  This may be a new feature.  One of the problems with the old way of doing it is that it would overwhelm Kibana if you had hundreds of namespaces.  It is much easier to just show "project.*" by default and let the user specify which namespace(s) to search for and view, rather than via the index pattern dropdown selector.

Comment 16 Rich Megginson 2017-11-13 19:46:32 UTC
I've removed the TestBlocker flag as I am not aware of any functionality which is prevented by this issue.

It might also not be a Regression, depending on if this new behavior is intentional.

Comment 20 Anping Li 2017-11-15 03:30:23 UTC
@rich, @Jeff, I can create index pattern for projects following the comment 15. But notice that there is no default index for ordinary user in kibana (refer to the snapshot "No default index for ordinary user"). 

To fix this bug. I think the expected result in kibana is as following. Please correct me if it is wrong.

1) The .all index can be found for all users in kibana. the user can retrieve the documents using .all index. The documents are from all indices the user owned.

2) The .operation index can be found when log in as cluster-admin or cluster-reader in kibana. the user can retrieve logs which are generated by the default project, the openshift project, openshift-infra project and operation system log. 
   The .operation index is not in the kibana when login as non cluster users
   The .operation index is only in ops kibana when ops kibana was enabled.

3) All indices can be list in kibana if the user own this project and the project has generated logs.

Comment 22 Jeff Cantrill 2017-11-17 13:12:54 UTC
@Anping.

Correction to item 1 of c#20.  The '.all' index is an alias that should be available only to users who are cluster-admin

Comment 23 Junqi Zhao 2017-11-20 09:23:27 UTC
@rmeggins
user can see the project indices by using workaround
https://bugzilla.redhat.com/show_bug.cgi?id=1511432#c15

But if there are a lot of projects, it will make customers disappointed if we let customers do the workaround manually

Comment 24 Junqi Zhao 2017-11-20 10:46:38 UTC
(In reply to Junqi Zhao from comment #23)
> @rmeggins
> user can see the project indices by using workaround
> https://bugzilla.redhat.com/show_bug.cgi?id=1511432#c15
> 
> But if there are a lot of projects, it will make customers disappointed if
> we let customers do the workaround manually

I mean if there are many projects, such as AA, BB, CC.., customers have to add project.AA*, project.BB*, .. indices to Kibana, if we jusut add project.* to Kibana, customers can not find every projects in Kibana

Comment 25 Rich Megginson 2017-11-21 17:55:03 UTC
(In reply to Junqi Zhao from comment #24)
> (In reply to Junqi Zhao from comment #23)
> > @rmeggins
> > user can see the project indices by using workaround
> > https://bugzilla.redhat.com/show_bug.cgi?id=1511432#c15
> > 
> > But if there are a lot of projects, it will make customers disappointed if
> > we let customers do the workaround manually
> 
> I mean if there are many projects, such as AA, BB, CC.., customers have to
> add project.AA*, project.BB*, .. indices to Kibana, if we jusut add
> project.* to Kibana, customers can not find every projects in Kibana

I'm not sure what you mean.

If we add only project.* to Kibana, customers can find every project.  They can find all of the projects they have permissions to see.

The only thing we are taking away from customers is the ability to have, by default, a "project.namespacename.*" index pattern for all of the projects/namespaces they have permissions to view, in the drop-down selector in the upper left hand corner on the Discover tab page.

Comment 26 Junqi Zhao 2017-11-22 00:33:14 UTC
(In reply to Rich Megginson from comment #25)
> (In reply to Junqi Zhao from comment #24)
> > (In reply to Junqi Zhao from comment #23)
> > > @rmeggins
> > > user can see the project indices by using workaround
> > > https://bugzilla.redhat.com/show_bug.cgi?id=1511432#c15
> > > 
> > > But if there are a lot of projects, it will make customers disappointed if
> > > we let customers do the workaround manually
> > 
> > I mean if there are many projects, such as AA, BB, CC.., customers have to
> > add project.AA*, project.BB*, .. indices to Kibana, if we jusut add
> > project.* to Kibana, customers can not find every projects in Kibana
> 
> I'm not sure what you mean.

See the attached picture " Snapshot 1", we have .all, project.logging.*, project.openshift-ansible-service-broker.* and other indices that can be selected from the left part.

If there are many projects, such as AA, BB, CC.. if we only add project.* index, we only can find project.* index in the left part of Kibana UI. We can not know the project name from the index. If we add project.AA*, project.BB*, .. indices to Kibana, it will make customers disappointed if they have many projects.

Comment 27 Rich Megginson 2017-11-22 01:29:18 UTC
(In reply to Junqi Zhao from comment #26)
> (In reply to Rich Megginson from comment #25)
> > (In reply to Junqi Zhao from comment #24)
> > > (In reply to Junqi Zhao from comment #23)
> > > > @rmeggins
> > > > user can see the project indices by using workaround
> > > > https://bugzilla.redhat.com/show_bug.cgi?id=1511432#c15
> > > > 
> > > > But if there are a lot of projects, it will make customers disappointed if
> > > > we let customers do the workaround manually
> > > 
> > > I mean if there are many projects, such as AA, BB, CC.., customers have to
> > > add project.AA*, project.BB*, .. indices to Kibana, if we jusut add
> > > project.* to Kibana, customers can not find every projects in Kibana
> > 
> > I'm not sure what you mean.
> 
> See the attached picture " Snapshot 1", we have .all, project.logging.*,
> project.openshift-ansible-service-broker.* and other indices that can be
> selected from the left part.

Right.  And that works fine when there are a very small number of projects.

> 
> If there are many projects, such as AA, BB, CC.. if we only add project.*
> index, we only can find project.* index in the left part of Kibana UI.

But that is not the only way to find projects.

> We can not know the project name from the index.

Correct, but there are other ways to find data for projects.

> If we add project.AA*,
> project.BB*, .. indices to Kibana, it will make customers disappointed if
> they have many projects.

Correct.

Comment 28 Junqi Zhao 2017-12-14 02:44:35 UTC
Please change to ON_QA, project indices could be found in kibana UI now.

Images
logging-kibana/images/v3.7.14-5
logging-fluentd/images/v3.7.14-5
logging-elasticsearch/images/v3.7.14-5
logging-auth-proxy/images/v3.7.14-5
logging-curator/images/v3.7.14-5

# openshift version
openshift v3.7.14
kubernetes v1.7.6+a08f5eeb62
etcd 3.2.8

Comment 29 Junqi Zhao 2017-12-14 02:45:15 UTC
Created attachment 1367755 [details]
project indices could be found on kibana UI.

Comment 30 Junqi Zhao 2017-12-14 04:26:50 UTC
set to VERIFIED as per Comment 28

Comment 31 Steven Walter 2018-01-23 23:54:45 UTC
Are we tracking this for a release soon? Customer has a production readiness deadline approaching, and considers this a blocker

Comment 32 Rich Megginson 2018-01-24 01:31:42 UTC
(In reply to Steven Walter from comment #31)
> Are we tracking this for a release soon? Customer has a production readiness
> deadline approaching, and considers this a blocker

@smunilla - did the last 3.7.z image release include logging-elasticsearch/images/v3.7.14-5 or later?  If not, is there an errata open already?

Comment 36 errata-xmlrpc 2018-04-05 09:30:40 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-2018:0636