-
Notifications
You must be signed in to change notification settings - Fork 83
Add the ability to set watch timeouts. #392
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
The test that is failing here is passing when i run it locally. Not sure what is happening here. !!
|
/assign @justinsb |
/test pull-declarative-test |
const WatchDelay = 30 * time.Second | ||
var ( | ||
// WatchActivityTimeout sets a timeout for a Watch activity under normal operation | ||
WatchActivityTimeout = 300 * time.Second |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could have a method to enable the watch activity timeout, but I actually think it's a really good defensive feature so I think we should enable it by default anyway. (If anyone disagrees, please comment!)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ack
Allow setting shorter watch timeout for the firt time alone. What this PR does / why we need it: We have seen in some evnironments (where requests are tunnelled) setting up the (first) watch is blocking if there are no resources available to watch. This causes the apply loop to be blocked when setting up watches before apply.
Thanks @barney-s /approve |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: barney-s, justinsb The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Allow setting shorter watch timeout for the first time alone.
What this PR does / why we need it:
We have seen in some evnironments (where requests are tunnelled) setting up the (first) watch is blocking if there are no resources available to watch. This causes the apply loop to be blocked when setting up watches before apply.