<p>I have deployed a service using Cloud run on gke which uses Knative as an abstraction over k8s. The default <code>MaxRevisionTimeoutSeconds</code> is set to 600s in the knative default <a href="https://github.com/knative/serving/blob/master/pkg/apis/config/defaults.go" rel="nofollow noreferrer">config</a> but according to this <a href="https://github.com/knative/serving/pull/4196/commits/e0d36f3bbf233f647f920a0f187f00b253b60f1f" rel="nofollow noreferrer">PR</a> this is customizable. </p>

<p>I couldn't find anything in the official Knative documentation, can anybody help me out here? </p>

<p><strong>UPDATE</strong>:</p>

<p>After digging a bit more in knative source code and documentation. It looks like that the <code>MaxRevisionTimeoutSeconds</code> is defined in <code>resource=ConfigMap/config-defaults</code>. So have to update it with custom value. </p>

<p>From <a href="https://knative.dev/docs/install/operator/configuring-serving-cr/#service-configuration-by-configMap" rel="nofollow noreferrer">this</a> it looks like we can use something called as <code>operator</code> to modify the ConfigMap resource but it did not work probably because gcp's does not use operator to install Knative components. Anyways I went on to install the operator and then used <code>resource=knativeserving</code> to overwrite the config-defaults. But this also did not work when I tried re-deploying service. </p>

<p>The next solution is to directly edit the config-defaults using <code>kubectl edit</code>. I even tried doing this but encountered weird behavior. After editing the YAML file when I used <code>kubectl describe</code> to check the changed value, it sometimes shows the modified value, sometimes shows the old value, and sometimes doesn't even show that particular key-value pair in the YAML. Also, it doesn't work when trying to re-deploy the service after doing this edit.</p>

<p>If anyone can help me with this, it would be really great. </p>

<p><code>MaxRevisionTimeoutSeconds</code> is a cluster-global setting which enforces the max value for <code>TimeoutSeconds</code> on each Revision. This value exists so that cluster administrators can set upper bounds on the amount of time a single HTTP request can be in the system. Knowing an upper bound can be useful when configuring graceful shutdown settings on the HTTP routing components to prevent dropped requests during upgrades.</p>

<p>It's possible that Cloud Run on GKE has overridden these configurations so that they can upgrade the underlying Istio and Knative components on a predictable schedule. (If you have a 10% upgrade budget and it takes 10m to drain a component, your minimum upgrade time is probably around 110m, taking into account additional scheduling / image fetch / startup time.)</p>
