Moving this backed to assigned until we merge 3.5
please let us know if you have some update and/or eta we could share with the customer Thank you Christian
Hello Jeff, Can you give us info which exact 3.5 image version will contain the fix? We would recommend the customer the workaround mentioned in: https://access.redhat.com/solutions/3211281 but we need to be confident that it will work with 3.5 and with which exact Image version. Thank you Christian
Please open an issue that is specific to what you are seeing as this fix is unrelated to what is reported in https://bugzilla.redhat.com/show_bug.cgi?id=1520629#c15
@Noriko From https://bugzilla.redhat.com/show_bug.cgi?id=1494612 I see Orphan index is added for logging 3.6 But I did not see Orphan index created for logging 3.5 Are my verification steps right to verify this defect? 1. Deploy logging 3.4 with pv and note down some project logs. 2. Upgrade logging 3.4 to 3.5, and check if the previous logs could be found. 3. Create new project to see if logs could be collected
(In reply to Junqi Zhao from comment #24) > @Noriko > From > https://bugzilla.redhat.com/show_bug.cgi?id=1494612 > I see Orphan index is added for logging 3.6 > > But I did not see Orphan index created for logging 3.5 > > Are my verification steps right to verify this defect? > 1. Deploy logging 3.4 with pv and note down some project logs. > 2. Upgrade logging 3.4 to 3.5, and check if the previous logs could be found. > 3. Create new project to see if logs could be collected Hi @Junqi, The implementation for the orphan index for 3.5 is different from 3.6+. The timing for the index creation might be also different from each other. When you say "I see Orphan index is added for logging 3.6", the index is empty or it has some data in it? oc exec $EPOD -- curl -s -k --cert /etc/elasticsearch/secret/admin-cert \ --key /etc/elasticsearch/secret/admin-key \ "https://localhost:9200/_cat/indices?v" When a log is missing kubernetes or kubernetes.namespace_id, it's indexed in the .orphaned index. Could it be possible to mimic such a situation and check if the orphaned logs are indexed in the .orphaned index or not? Thanks!
(In reply to Noriko Hosoi from comment #25) > When you say "I see Orphan index is added for logging 3.6", the index is > empty or it has some data in it? > oc exec $EPOD -- curl -s -k --cert /etc/elasticsearch/secret/admin-cert \ > --key /etc/elasticsearch/secret/admin-key \ > "https://localhost:9200/_cat/indices?v" Orphan index is only applicable for logging 3.6 and above, 3.5 does not have Orphan index
After upgrade from logging 3.4 to 3.5, recent logs and new project logs could be shown. # openshift version openshift v3.5.5.31.67 kubernetes v1.5.2+43a9be4 etcd 3.1.0 logging-elasticsearch/images/v3.5.5.31.67-2 logging-curator/images/v3.5.5.31.67-4 logging-fluentd/images/v3.5.5.31.67-2 logging-kibana/images/v3.5.5.31.67-2 logging-auth-proxy/images/v3.5.5.31.67-2
After upgrade from logging 3.4 to 3.5, recent logs and new project logs could be shown. # openshift version openshift v3.5.5.31.67 kubernetes v1.5.2+43a9be4 etcd 3.1.0 logging-auth-proxy/images/v3.5.5.31.67-1 logging-curator/images/v3.5.5.31.67-3 logging-elasticsearch/images/v3.5.5.31.67-1 logging-kibana/images/v3.5.5.31.67-1 logging-fluentd/images/v3.5.5.31.67-1
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/RHSA-2018:1235