Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Configurable timeout for resource checks #2352
The ATC should have a configurable
This should also be configurable at a per-resource level, and override the deployment level default
Do timeouts have some effect on the check interval? Maybe a consistently timing out resource could
Should custom resource type checking timeouts include the time spent checking for the custom type? My thought is it shouldn't, but the contract to the user is important here;
We should look at how *deep breath*
Resource check timeouts and resource type check timeouts should be separate stories, as they have pretty different implementation requirements:
@pivotal-jamie-klassen Good points! To be honest we should really think about surfacing resource types in the web UI soon, and I think users will really like being able to do all the things they can with resources with resource types. Resource type developers for example would love to be able to force a check, and it's obviously helpful to see check errors there too.
I think while we're working on #2386 we should keep this in mind, and we should support doing the same things you can with resources as with resource types. Maybe with a generic "resource config" API/UI? Just spitballing, but this could also be useful for things like concourse/rfcs#7 which introduces yet another toplevel "resourcey" concept.
We decided to create a default value of
Why a default?
Sometimes resource checks run for a long time, for one of two reasons:
While we might shock the people in column 1, we can suggest they increase their timeout and return to happiness. The greater good is served because we might be able to save the people in column 2 from their ignorance.
Long-running resource checks seem pretty normal. Longer than 1 hour is unreasonable, because that is the max expiry period for a resource check container -- if the container is considered stale, the check should certainly be considered timed out.
#2352 Submodule src/github.com/concourse/atc 8d030443a..e904dc7d5: > Configurable timeout for resource checks Submodule src/github.com/concourse/testflight 44b41dc37..a47221a84: > Configurable timeout for resource checks > fixtures and test for resource check timeouts Signed-off-by: Saman Alvi <firstname.lastname@example.org>
@topherbullock While working on #2386, @clarafu and I found that supporting pipeline-configurable check timeouts is really awkward once resource histories and checking are global. We would either have to enforce the shortest configured timeout for everyone (which seems exploitable), or only enforce it if/when the pipeline that acquired the lock has a timeout configured (which seems ineffective).
I wonder if we can get away with having only the global setting? A global default makes a lot of sense for the operator to defend against stuck resources/resource types, but I can't think of any scenarios where I, as a pipeline author, would proactively enforce timeouts on my resources. I guess you might want to configure it after you see something going wrong, but it's not so easy to notice that in the first place...