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 1356875 - [Intservice_public_234] Not able to view metrics charts on webconsole UI until tuning to the re-encrypted hawkular-metrics route in a seprated tab
Summary: [Intservice_public_234] Not able to view metrics charts on webconsole UI unti...
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Hawkular
Version: unspecified
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
: ---
Assignee: Matt Wringe
QA Contact: chunchen
Depends On:
TreeView+ depends on / blocked
Reported: 2016-07-15 07:48 UTC by Xia Zhao
Modified: 2018-07-26 19:09 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2016-09-19 13:56:11 UTC
Target Upstream Version:

Attachments (Terms of Use)

Description Xia Zhao 2016-07-15 07:48:30 UTC
Problem description: 
Not able to view metrics data charts on webconsole UI until tuning to the reencrypted hawkular-metrics route in a seprated tab.
Issue reproduced no matter whether the default router certificate or custom certificate is used by metrics.

Version-Release number of selected component (if applicable):
openshift/origin-metrics-cassandra    f162d7bca413
openshift/origin-metrics-hawkular-metrics    5b13c7358533
openshift/origin-metrics-heapster    b1d4a45f6b30
openshift/origin-metrics-deployer    4a0f57c10615

How reproducible:

Steps to Reproduce:
1. Deploy metrics components with steps in
2. After HCH pods are running fine, check that the reencrypted hawkular-metrics route is deployed
3. Verify certificate for the endpoint is the expected ones:
curl --resolve $HOST/PORT:443:$router_pod_ip https://$HOST/PORT -k --cacert $custom_CA 
(or using $default_router_CA in part --cacert if metrics is deployed without custom cert)
make sure it is working:
# curl --resolve hawkular-metrics.router.default.svc.cluster.local:443: https://hawkular-metrics.router.default.svc.cluster.local --cacert cloudapps.router.pem
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
  <meta http-equiv="refresh" content="0;hawkular/metrics">
  <title>Hawkular Metrics</title>

  <h1>Hawkular Metrics</h1>
  <h3>A time series metrics engine based on Cassandra</h3>
4. Check the route type, make sure it's reencrypted:
# oc get route -n xiazhao
NAME               HOST/PORT                                                      PATH      SERVICE                           TERMINATION   LABELS
hawkular-metrics   hawkular-metrics.router.default.svc.cluster.local ... 1 more             hawkular-metrics:https-endpoint   reencrypt     metrics-infra=hawkular-metrics,name=hawkular-metrics
5. Go to openshift webconsole, check the charts under metrics tab without tuning to the hawkular-metrics route 

Actual Result:
4. Not able to view metrics data charts, get these error:
Metrics are not available.
An error occurred getting metrics for container hawkular-metrics from https://hawkular-metrics.router.default.svc.cluster.local/hawkular/metrics.
Status code 0

Still have to tune to the reencrypted hawkular-metrics route in a seprated tab of browser in order to view the metrics charts 

Expected Result:
4. Should be able to view metrics charts on webconsole UI without tuning to the reencrypted hawkular-metrics route in a seprated tab

Additional info:

Comment 1 Matt Wringe 2016-07-15 13:58:03 UTC
I don't understand the question here.

If you are saying that you have to go to a separate tab and click on something like 'trust this certificate/connection' before metrics will start to be displayed. Then that is always the expected default behaviour if you are using self signed certificates.

There is noting we can do about that. The only better solution would be for OpenShift to provide a proxy under the same hostname as the master so the user would only need to accept the console's certificate and not also the Hawkular Merics one.

Using a reencrypting route doesn't help anything with the double certificate authorization issue. Its just makes providing your own certificates an easier than the setup we had before.

Ways to get around this situation is to sign your certificate with an authorized certificate authority.

This can mean signing it with a certificate authority that is trusted by all browsers by default. This is done exactly the same way that any website on the internet does to ensure their sites can be accessed without issue over https.

This can also mean manually configuring your browser to accept all certificates signed by a own custom certificate authority. For instance, if you are a company and you are running a bunch of internal sites and services, you may require your employees to configure their browser to trust the company's certificate authority. Doing this will mean that all internal sites would then be accepted by the browser.

Comment 2 Xia Zhao 2016-07-18 02:20:56 UTC
@mwringe Thanks for the explanation. Understood. Could you please transfer this back to on_qa for closure? Thanks!

Comment 3 Xia Zhao 2016-07-19 06:23:23 UTC
Set to verified according to comment #1, end user still have to trust their self signed certificate to hawkular before metrics start to be displayed unless "manually configuring your browser to accept all certificates signed by a own custom certificate authority". The reencrypting route actually help mothing here, and this is expected.

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