Description of problem: Suppress the rejected routes in haproxy if router shards are used Version-Release number of selected component (if applicable): OpenShift Container Platform 3.4 How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: I0822 20:58:37.325736 1 router.go:223] Router is only using routes in namespaces matching ---- E0822 19:12:86.333333 1 host_admitter.go:121] Route default/docker-registry not admitted: host not in the allowed list of domains Expected results: --- Additional info:
Created PR for review: https://github.com/openshift/origin/pull/18511
Ben and I discussed this yesterday and today; following are the pertinent points of that discussion. A shard is defined by the route or namespace label selector with which the router is configured. The router uses the label selector when it lists and watches routes, so it will not even see routes that do not match the selector (and therefore do not belong to the shard). In the original report, it appears the router is also configured with a domain whitelist, so any route in the shard must have a hostname belonging to a whitelisted domain. If a router configured with a label selector sees a route that is rejected because of its hostname, that means the route specifies a label that causes it to belong to a shard (as defined by the label selector) but also specifies a hostname that does not belong to the shard (as defined by the shard's domain whitelist). This contradiction means that the shard or the route is defined incorrectly (namely, one or more of the label selector, the domain whitelist, the route label, or the route host is incorrect). Important to note is that the route is being rejected because of the domain whitelist, which is not a sharding-specific feature, so inhibiting the log message if (and only if) sharding is enabled does not seem to make sense. Also, it looks like the proposed PR suppresses logging of *all* rejections from the admitter in sharded routers. For example, the admitter could reject the route because it violates wildcard policy. Whether or not that rejection should be logged does not seem to be related to whether sharding is used. Ben pointed out that the person configuring the router and the person defining the route may be two different people. The router should not necessarily annoy the former person with log messages for the second person's mistakes, and the second person should already be able to see the rejection reason in the route status. On the other hand, it may be useful to administrators to have the *option* of logging rejection reasons by setting some very high log level. In sum, • The reporter may want to verify that the shard is correctly defined (in which case it appears the route is incorrectly defined). • The issue of logging rejections does not appear to be sharding-specific. • The proposed PR appears to be overly broad in what it suppresses. • Rejection reasons are already in route status so users can see them. • We should bump the level at which we log rejections so admins don't see them. Does that all seem reasonable?
Created a new PR based on Miciahs comments: https://github.com/openshift/origin/pull/18620
Verified this bug on v3.9.0-0.53.0 now the related logs will not be found: I0227 10:32:17.978434 1 router.go:220] Router is only using routes in namespaces matching team=red I0227 10:32:18.316864 1 router.go:441] Router reloaded: - Checking http://localhost:80 ... - Health check ok : 0 retry attempt(s).
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-2018:0489