Bug 1355711 - Should trigger the router resync when adding label to namespace which matches the router namespace_label
Summary: Should trigger the router resync when adding label to namespace which matches...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Networking
Version: 3.2.1
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ---
: ---
Assignee: Ben Bennett
QA Contact: Meng Bo
URL:
Whiteboard:
Depends On:
Blocks: 1267746
TreeView+ depends on / blocked
 
Reported: 2016-07-12 10:07 UTC by Meng Bo
Modified: 2022-08-04 22:20 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-10-26 21:39:41 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
router_log (8.50 KB, text/plain)
2016-07-12 10:07 UTC, Meng Bo
no flags Details

Description Meng Bo 2016-07-12 10:07:12 UTC
Created attachment 1178842 [details]
router_log

Description of problem:
After router with NAMESPACE_LABELS env created, it will sync the namespace which matches the label every 10 mins.
This will cause the new created namespace with specified label cannot be served by the router.

NamespaceSyncInterval: factory.ResyncInterval - 10*time.Second
ResyncInterval: 10 * time.Minute

We should trigger the resync once the namespace was added the label.

Version-Release number of selected component (if applicable):
v3.2.1.5-1-g71b9ccf
ose-haproxy-router: ac5b044016d2

How reproducible:
always

Steps to Reproduce:
1. Setup env with router running
2. Modify router with NAMESPACE_LABELS
# oadm policy add-cluster-role-to-user cluster-reader system:serviceaccount:default:router
# oc env dc/router NAMESPACE_LABELS=team=red
3. Wait for the new router pod running
4. Create project and add label to it
# oc label namespace u1p1 team=red
5. Create route in the project
6. Access the route
7. Wait for 10 minutes and access the route again

Actual results:
6. The route cannot be served by the router with same label after created.
7. The route available after the router resync in 10 minutes.

Expected results:
Route created project with namespace_label which added after router created should trigger the router resync and can be accessed immediately. At least should not have about 10 minutes down time.

Additional info:
Router log with loglevel 4 attached.

Comment 2 Maru Newby 2016-08-16 03:23:39 UTC
The router watches for changes to routes and endpoints, but only queries namespace state on startup and every subsequent sync interval.  Fixing this bug will require that the router watches for namespace changes as well.  Is this increase in complexity desirable this close to release?

Comment 3 Eric Paris 2016-08-16 13:05:02 UTC
I vote no. Work on this for 3.4.

Comment 4 Maru Newby 2016-08-16 15:16:22 UTC
Ok, will postpone.

Another complication with the current router design is that a router does not keep track of routes that don't (currently) match the set of namespaces it is targeted at.  If a router was selecting on namespaces with a given label, and a route was added to a namespace without the label, the router would not keep track of that route.  Even if the router was updated to watch for namespace changes, setting the required label on the namespace would only ensure that the route was picked up on a subsequent sync event.  In order to ensure that routes are always picked up outside of sync events, it would be necessary for a router to both watch for namespace changes and keep track of all routes regardless of whether they would be exposed by the filtering state at time of processing.

Comment 5 Ben Bennett 2016-08-16 17:26:17 UTC
Is it possible to trigger a full resync when a label is added?

Comment 6 Maru Newby 2016-08-16 18:02:46 UTC
(In reply to Ben Bennett from comment #5)
> Is it possible to trigger a full resync when a label is added?

Yes, that would be possible.  Given how much work is involved in a full sync, though, there would have to be limits on how often it could be triggered or namespace/project labeling could be used to dos the router.

Comment 7 Clayton Coleman 2016-10-05 17:38:02 UTC
This is working as designed, specifically to reduce the cost to transform.  I'd recommend this as WONTFIX until we potentially switch to Informers in the future.  But even then, it's marginal utility.

Comment 8 Ben Bennett 2016-10-24 19:57:51 UTC
*** Bug 1382388 has been marked as a duplicate of this bug. ***

Comment 9 Eric Paris 2016-10-26 21:39:41 UTC
I apologize, however, this request for enhancement is not planned for the near future. I am going to close this BZ as WONTFIX. If you wish for us to reconsider please discuss the impact of this feature with your support representative and we may consider re-openning the request.

Comment 10 Maru Newby 2017-01-24 17:35:12 UTC
*** Bug 1415112 has been marked as a duplicate of this bug. ***


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