Description of problem: Logging operator should publish sharing-config configmap into openshift-config-managed namespace, so it's reachable for other components, like console, which needs to access to: - kibanaAppURL - kibanaInfraURL Version-Release number of selected component (if applicable): 4.4. How reproducible: Always Steps to Reproduce: 1. 2. 3. Actual results: Logging operator is publishing sharing-config configmap into openshift-logging namespace. If any component needs to get hands on the configmap it needs to get additional RBAC permissions. Expected results: Logging operator should be publishing sharing-config configmap into openshift-config-managed namespace so no additional RBAC permissions needs to be added to component that needs the configmap.
For the new configmap name I would be in favour either for "logging" as suggested or maybe "logging-shared-config"
logging-shared-config would be consistent with the monitoring-shared-config that was recently merged: https://bugzilla.redhat.com/show_bug.cgi?id=1803192 Consistency is good.
the fix for the original request is being reverted due to: https://bugzilla.redhat.com/show_bug.cgi?id=1807739 moving back to NEW.
Since the logging operator is OLM and not CVO, the publishing of the config into `openshift-config-managed` isn't the correct approach. Instead, we have a `ConsoleLink` CRD that fits this use case. See: - CRD https://github.com/openshift/api/blob/master/console/v1/0000_10_consolelink.crd.yaml - API https://github.com/openshift/api/blob/master/console/v1/types_console_link.go Locations options for the link at this point are (https://github.com/openshift/api/blob/master/console/v1/types_console_link.go#L20): - ApplicationMenu (with additional config options) - HelpMenu - UserMenu - NamespaceDashboard (with additional config options) We would suggest using ApplicationMenu. There is an optional Section if desired.
What is the difference between kibana-app-public-url and kibana-infra-public-url ? #oc get ConsoleLink kibana-app-public-url -o json |jq '.spec' { "applicationMenu": { "section": "Monitoring" }, "href": "https://kibana-openshift-logging.apps.anli45515.qe.devcluster.openshift.com", "location": "ApplicationMenu", "text": "Logging" } #oc get ConsoleLink kibana-infra-public-url -o json |jq '.spec' { "applicationMenu": { "section": "Monitoring" }, "href": "https://kibana-openshift-logging.apps.anli45515.qe.devcluster.openshift.com", "location": "ApplicationMenu", "text": "Logging" }
@yapei Could you help me confirm if the Logging works on Console? The user can be directed from pod->logs to kibana. Is there any other link can be directed to kibana? For example: Monioring->xxx.
@anping & yapei I will put this on needsinfo until yapei provides the info. AFAIK there should be a link for Logging on the Application Menu Monitoring -> Logging that opens Kibana.
The Application Menu Monitoring -> Logging disappeared. If I add the configmap/sharing-config manually, the menu appears. Shall the console use consoleexternalloglinks.console.openshift.io?
If cluster logging is deployed successfully and clusterlogging/instance is running(kibana route is created) then admin user can see Monitoring -> Logging menu
@Anping Li & @Yadan Pei You should not use the configmap any more to get the application menu link for "Logging". If this is the case then this is not a bug in elasticsearch-operator but probably a bug on the console-operator side. Can you please re-check this? Elasticsearch-operator is not responsible for the UI but simply for creating the ConsoleLink CRs for the application menu. ConsoleExternalLinks are used only for the pod detail view.
Agree. Move to verify and Filed a console bug https://bugzilla.redhat.com/show_bug.cgi?id=1840478
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
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days