Merge pull request kubernetes#1507 from wking/faster-update-PromQL-cache-warming

enhancements/update/targeted-update-edge-blocking: 1s between different PromQL

Author: openshift-ci[bot]

enhancements/update/targeted-update-edge-blocking.md

@@ -320,7 +320,7 @@ Additionally, the operator will continually re-evaluate the blocking conditional
 The timing of the evaluation and freshness are largely internal details, but to avoid [consuming excessive monitoring resources](#malicious-conditions) and because [the rules should be based on slowly-changing state](#clusters-moving-into-the-vulnerable-state-after-updating), the operator will handle polling with the following restrictions:
 
 * The cluster-version operator will cache polling results for each query, so a single query which is used in evaluating multiple risks over multiple conditional update targets will only be evaluated once per round.
-* After evaluating a PromQL query, the cluster-version operator will wait at least 10 minutes before evaluating any PromQL.
+* After evaluating a PromQL query, the cluster-version operator will wait at least 1 second before evaluating any PromQL.
     This delay will not be persisted between operator restarts, so a crash-looping CVO may result in higher PromQL load.
     But a crash-looping CVO will also cause the `KubePodCrashLooping` alert to fire, which will summon the cluster administrator.
 * After evaluating a PromQL query, the cluster-version operator will wait at least an hour before evaluating that PromQL query again.
@@ -687,6 +687,8 @@ If the Prometheus implementation is not sufficiently hardened, malicious PromQL
 [Future monitoring improvements][mon-1772] might reduce the risk of expensive queries.
 And it's also possible to teach the cluster-version operator to reject PromQL that does not match expected patterns.
 
+Attacks can also be mitigated by pointing ClusterVersion `spec.upstream` at an uncompromised update service, or by clearing `channel` to ask the CVO to not retrieve update recommendations at all.
+
 #### Clusters without local Prometheus stacks
 
 The Prometheus and monitoring stacks are fairly resource-intensive.