More aggressive Revision GC settings

[mattmoor]

In what area(s)?

/area API
/kind spec

Describe the feature

An issue was recently raised around the volume of Revisions that are produced (and retained) in tight edit loops (think: fsnotify).

Today we have 3 knobs that control the GC of Revisions:

1. The minimum depth of revisions to retain (stale-revision-minimum-generations ),
2. The minimum duration of time to keep a Revision (stale-revision-create-delay ), and
3. How long to keep a Revision after it was last routable (stale-revision-timeout ).

The defaults for these is to keep Revisions for two days after creation, 15 hours since last routable, or 20 revisions, whichever keeps more, but today (in part given how we implement things currently) the lowest we allow on the duration is the controller resync period (10 hours) because of how it's implemented.

However, for systems that don't take advantage of the Revision mechanism, it would be nice to be able to set the durations to O(minutes) (or seconds) and the retention window to 1-2 revisions.

cc @michal-hudy @evankanderson @dprotaso

[evankanderson]

The fsnotify case where "deploy" is basically being used in the development inner-loop is interesting.

A few different approaches:

1. Reduce the number of revisions via more aggressive GC. We probably want to keep (at a minimum) all working revisions since the one assigned traffic, as well as the most recent failed deployment (for debugging).

2. More aggressively collapse Revisions older than the oldest in-service Revision, such that we don't provision a Deployment, Service, etc for them. This would add some additional state to the Revision lifecycle, and would make it take longer for those Revisions to be put back into active usage. There's a potential risk here of making it slightly slower to "roll back quickly" if you're doing 100% traffic shifts as your day-to-day routine, but that may be an acceptable tradeoff, or maybe we can have some more-clever heuristics.

[whaught]

/assign