github.com/operator-framework/operator-lifecycle-manager@v0.30.0/doc/design/default-polling.md (about)

     1  # Supporting default polling for catalogs
     2  
     3  ## Description
     4  
     5  Catalog polling is currently an opt-in feature that enables catalog users to push new content to the same image tag and have
     6  that content brought into the cluster asynchronously by OLM. This is an opt-in feature that is enabled on the catalog
     7  by setting an `UpdateStrategy` on the spec. 
     8  
     9  The proposal is to enable default polling for all catalogs on the cluster, except for those that are backed by an image digest
    10  (since the content of those are not upgradeable by definition). 
    11  
    12  ## Pros of default polling
    13  * Catalogs stay up to date by default, providing a nice UX
    14  * Polling becomes opt-out instead of opt-in, requiring users to know less of the OLM APIs to get catalog updates
    15  
    16  ## Cons of default polling
    17  * More cluster egress - polling will pull images on a continuous basis regardless of whether the user is actually expecting 
    18  the catalog to be upgraded 
    19  * Declarative config - kubernetes is based around a declarative model where the user describes their desired state and the system
    20  works to reconcile that state. By providing defaults that are not explicitly mentioned in the spec of the catalog source object
    21  that principle is violated
    22  * This may not be useful at all in the case of disconnected environments 
    23  
    24  ## Open Questions
    25  * What should the default polling interval be?
    26  * Should the defaulting behavior be implemented via a mutating admission webhook, or by OLM when creating the catalog?  
    27  * Should there be an explicit opt-out besides using a digest-based catalog image?