Description of problem: After logging is deployed, and logging url is set in sharing-config, check logging nav under Monitoring menu, the Logging nav is not shown up. Version-Release number of selected component (if applicable): # ./bin/openshift-install version ./bin/openshift-install v0.8.0-master-2-g5e7b36d6351c9cc773f1dadc64abf9d7041151b1 $ oc get clusterversion registry.svc.ci.openshift.org/openshift/origin-v4.0-2018-12-26-190509@sha256 86f6104f0b2d69a5c0133fa92f2325bbc78c398ba1000f10927f3a9d3b36e792 7f8e4a1588a2 6 days ago 268 MB console repo commit id: c7f598d85ba30c2a8347885d66e44d2c8be448f5 How reproducible: Always Steps to Reproduce: 1. Deploy logging in the env. Make sure logging url is set. # oc get cm sharing-config -n openshift-logging -o yaml apiVersion: v1 data: kibanaAppURL: https://kibana-openshift-logging.apps.qitang.origin-ci-int-aws.dev.rhcloud.com kibanaInfraURL: https://kibana-openshift-logging.apps.qitang.origin-ci-int-aws.dev.rhcloud.com ....... 2. Login admin console with cluster admin, Check logging nav under Monitoring menu. 3. Actual results: 2. the Logging nav is not shown up. Expected results: 2. Should show Logging nav under Monitoring menu. Additional info:
The sharing-config config map needs to be readable by authenticated users for the logging nav item to show up. This would be consistent with openshift-monitoring cm/sharing-config. Right now, the console can't read the config. Changing component to Logging.
https://github.com/openshift/cluster-logging-operator/pull/71
# oc get clusterversion NAME VERSION AVAILABLE PROGRESSING SINCE STATUS version 4.0.0-0.alpha-2019-01-08-224750 True False 6h Cluster version is 4.0.0-0.alpha-2019-01-08-224750 console image version: registry.svc.ci.openshift.org/openshift/origin-v4.0-2019-01-08-224750@sha256 eea2d43184040ea2f6a0cf76b58b707340335ee3ac11f259acae7ee9f2f2f22a fa9a11ecac56 16 hours ago 268 MB console repo commit id: 53b4b210502d0304dbc22631592fff09dfe7c78a logging related images: quay.io/openshift/origin-cluster-logging-operator latest 7f691fb7d6f4 9 hours ago 302 MB docker.io/openshift/origin-logging-curator5 latest 5e593b8e5966 11 hours ago 236 MB docker.io/openshift/origin-logging-elasticsearch5 latest b1fda52449c9 11 hours ago 424 MB docker.io/openshift/origin-logging-fluentd latest a826806e8ff4 11 hours ago 697 MB logging url is set in share-config cm: data: kibanaAppURL: https://kibana-openshift-logging.apps.qitang.devcluster.openshift.com kibanaInfraURL: https://kibana-openshift-logging.apps.qitang.devcluster.openshift.com Checked on env with above images versions, user still could not found logging url under Monitoring menu on console.
Assuming the permissions are correct and the role ('shared-config-reader'), binding, and configmap exist, will the console dynamically load the shared config? To resolve the issue might we need to restart the console?
You shouldn't need to restart the console, only refresh the page. I'd open the network tab in Chrome developer tools to check the console request for the sharing-config config map in the openshift-logging namespace. If it failed, look at what at the error details. (Note that there are two requests, one for openshift-monitoring and one for openshift-logging.)
The console is looking at the wrong property in the config map.
https://github.com/openshift/console/pull/1079
The fix is not contained in v4.0.0-0.139.0.0. Will check when there is new build/image.
$ oc get clusterversion NAME VERSION AVAILABLE PROGRESSING SINCE STATUS version 4.0.0-0.nightly-2019-01-18-115403 True False 5h Cluster version is 4.0.0-0.nightly-2019-01-18-115403 console image: registry.svc.ci.openshift.org/ocp/4.0-art-latest-2019-01-18-115403@sha256 0c65f4d65acb6d7432637a33cdda6de8b23b5743706203f9fa58543530c26d21 5db9df437682 4 days ago 261 MB console repo commit: 2dc8614b6f0975fe579a21b2e2cedf1f186af8e4 Checked on ocp env with above version, after logging is deployed, check Logging url on console with cluster admin user, now there is menu "Monitoring"_>"Logging", and click on "Logging", it will open correct logging url. The bug has been fixed, so move it to Verified.