Bugzilla (bugzilla.redhat.com) will be under maintenance for infrastructure upgrades and will not be unavailable on July 31st between 12:30 AM - 05:30 AM UTC. We appreciate your understanding and patience. You can follow status.redhat.com for details.
Bug 1813209 - Kibana console isn't accessible when enabled https_proxy in the cluster.
Summary: Kibana console isn't accessible when enabled https_proxy in the cluster.
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Logging
Version: 4.4
Hardware: Unspecified
OS: Unspecified
medium
high
Target Milestone: ---
: 4.5.0
Assignee: ewolinet
QA Contact: Qiaoling Tang
URL:
Whiteboard:
Depends On: 1823606 1826793
Blocks: 1818650 1818651
TreeView+ depends on / blocked
 
Reported: 2020-03-13 09:23 UTC by Qiaoling Tang
Modified: 2020-07-13 17:20 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1818650 1818651 (view as bug list)
Environment:
Last Closed: 2020-07-13 17:19:58 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2020:2409 0 None None None 2020-07-13 17:20:26 UTC

Comment 7 Michael Burke 2020-03-30 01:33:42 UTC
Cloned as docs bug: https://bugzilla.redhat.com/show_bug.cgi?id=1818651

Comment 13 Michael Burke 2020-03-31 00:17:11 UTC
I did not have to redeploy cluster logging. I updated proxy/cluster to add some proxy information. Could not get into Kibana. I edited proxy/cluster to add `.apps.<cluster_name>.<base_domain>` and was able to access Kibana.

Is that how this should work?

Eric, how do we inject the trusted CA into the Kibana pod?

Comment 16 Qiaoling Tang 2020-04-01 02:04:09 UTC
I tried to delete the deploy/kibana, then wait for the new deploy/kibana to be created, the `.apps.<cluster_name>.<base_domain>` is added to the no_proxy and NO_PROXY env variables in the new deployment/kibana.

The old deploy/kibana
http://pastebin.test.redhat.com/850462

The new deploy/kibana
http://pastebin.test.redhat.com/850465

Comment 17 Michael Burke 2020-04-01 02:08:21 UTC
>The trusted CA should be injected into a configmap for the kibana pod to consume and use.

How does the user do this?

Comment 18 ewolinet 2020-04-01 15:07:36 UTC
>I tried to delete the deploy/kibana, then wait for the new deploy/kibana to be created, the `.apps.<cluster_name>.<base_domain>` is added to the no_proxy and NO_PROXY env variables in the new deployment/kibana.

Right, the deployment needs to be updated. Was the operator not doing this in time? It did on my own local cluster...


>How does the user do this?

The user doesn't do that directly. They would be updating the additional trust bundle for the proxy/cluster object as described here [1].


[1] https://docs.openshift.com/container-platform/4.3/networking/configuring-a-custom-pki.html#nw-proxy-configure-object_configuring-a-custom-pki

Comment 19 Qiaoling Tang 2020-04-02 01:28:34 UTC
> >I tried to delete the deploy/kibana, then wait for the new deploy/kibana to be created, the `.apps.<cluster_name>.<base_domain>` is added to the no_proxy and NO_PROXY env variables in the new deployment/kibana.
> 
> Right, the deployment needs to be updated. Was the operator not doing this
> in time? It did on my own local cluster...
> 

Yes, in my cluster, the CLO didn't update the deploy/kibana.

Comment 21 ewolinet 2020-04-08 14:03:26 UTC
Michael, we should not be advising users to delete deployment objects.


Qiaoling, were there any errors in your CLO pod? Something to indicate something was stalled/stuck? The updating of env vars is the same as any other updates the operator would do to the deployment (resources, image name, etc).

Comment 23 Qiaoling Tang 2020-04-14 02:23:08 UTC
Hi Eric, I opened a new bug to track the issue that the CLO couldn't update the deploy/kibana after the cluster proxy changed, here is the bug: https://bugzilla.redhat.com/show_bug.cgi?id=1823606

Comment 24 Periklis Tsirakidis 2020-05-22 07:23:29 UTC
Blocked by https://bugzilla.redhat.com/show_bug.cgi?id=1826793 because PR needs cherry-pick approval

Comment 25 ewolinet 2020-05-27 21:12:05 UTC
It looks like prior blockers have been verified, can we please retest this?

Comment 26 Qiaoling Tang 2020-06-01 02:57:58 UTC
I'll test it when I could launch a cluster with https_proxy, currently, my jobs are failed. I'll update the status when I finish my testing.

Comment 30 errata-xmlrpc 2020-07-13 17:19:58 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-2020:2409


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