Allow custom handling of config-default.

[Cynocracy]

Describe the feature

As a platform operator, I would like to change the behavior of my flavor of Knative such that the 'default default' (or the behavior of config-default when a key is not present, defined here:

serving/pkg/apis/config/defaults.go

Line 46 in ac91f26

DefaultMaxRevisionTimeoutSeconds = 10 * 60

) is custom to my installation.

This would be useful for platform operators which are specializing, and may want to as an example enforce very short or very long deadlines by default.

[Cynocracy]

The simplest fix for this is just to make these flags.

Any objections?

[julz]

I didn't quite follow why such an operator wouldn't want to apply those customisations to their config-defaults configmap directly?

[Cynocracy]

Ah, there's a quirk in our current platform where we don't have the ability to set a value and allow it to be trivially user controlled in a configmap.

Thus, we need the 'value not present' default to match our desired system default.

[markusthoemmes]

That seems to be counter-intuitive regarding the reason to have config-default in the first place IMO. We'd have a hard time explaining why we have both flags AND a config map expressing essentially the very same thing.

[mattmoor]

I think what Jon's driving at is that there's a nuanced distinction between the cluster operator and the platform provider, and the configmap is generally targeting the former, but the latter may want to adjust things themselves.

Flags is one way of doing this, another would be to change these to var and use linker flags or the ./cmd entrypoint to change default values in-context.

[julz]

Have to admit, I'm struggling to see the use case where you're willing to pass different flags (so modify images/yaml), but can't use kustomize (or similar) to modify the config map. If what we want is an ability to have different sets of defaults for different users (e.g. per-namespace defaults), that seems like a use case for #8114 (which I'm a big fan of.. maybe we should bump that up the priority list).

[github-actions]

This issue is stale because it has been open for 90 days with no
activity. It will automatically close after 30 more days of
inactivity. Reopen the issue with /reopen. Mark the issue as
fresh by adding the comment /remove-lifecycle stale.