Bug 1355711

Summary: Should trigger the router resync when adding label to namespace which matches the router namespace_label
Product: OpenShift Container Platform Reporter: Meng Bo <bmeng>
Component: NetworkingAssignee: Ben Bennett <bbennett>
Networking sub component: router QA Contact: Meng Bo <bmeng>
Status: CLOSED WONTFIX Docs Contact:
Severity: medium    
Priority: medium CC: akokshar, aos-bugs, bbennett, ccoleman, eparis, hongli, mnewby
Version: 3.2.1   
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-10-26 21:39:41 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1267746    
Attachments:
Description Flags
router_log none

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. ***