Description of problem: When deploying metrics if the route is never accepted by a router, the cluster-monitoring-operator will loop forever waiting for route to become ready, with no log showing why its not progressing creating the other objects. Version-Release number of selected component (if applicable): 3.11 4.0 How reproducible: 100% Steps to Reproduce: 1. Configure Router sharding all router deployment 2. No way to set a default shard label with out configuring a customer default project template. 3. Deploy cluster-monitoring Actual results: Loop for ever preforming a GET on the grafana route. round_trippers.go:383] GET https://172.22.0.1:443/apis/route.openshift.io/v1/namespaces/openshift-monitoring/routes/grafana Expected results: At the very least log an error Then either continue with loop or move forward creating the rest of the metrics objects, while still checking for route to become ready logging more verbosely what its waiting on. Additional info: https://github.com/openshift/cluster-monitoring-operator/blob/master/pkg/client/client.go#L497-L502 https://github.com/openshift/cluster-monitoring-operator/blob/release-3.11/pkg/client/client.go#L377-L381
A similar bug was filed here: bz1666936 (copied to https://jira.coreos.com/browse/RFE-13)
(In reply to Robert Bost from comment #1) > A similar bug was filed here: bz1666936 (copied to > https://jira.coreos.com/browse/RFE-13) Since the bug mentioned above was created to request improvements on the errors, can this bug be used to track an improvement in the Route created by the operator? Or should some other method be used?
I think the two can be combined as one. I am linking this bug zilla ticket in the RFE-13 Jira ticket.
@Ryan I'm unfamiliar with route sharding. Is it possible to always set the "default" route sharding? These routes are super low in traffic so I'd like to find a solution that involves no configuration by customers.
Closing this in favor of the RFE in Jira.