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

     1  # Catalog Polling
     2  
     3  ## Description
     4  It is possible to configure the catalog source to poll a source, such as an image registry, to check whether the
     5  catalog source pod should be updated. A common use case would be pushing new bundles to the same catalog source tag, and seeing
     6  updated operators from those bundles being installed in the cluster. Currently polling is only implemented for image-based catalogs
     7  that serve bundles over gRPC. 
     8  
     9  For example, say currently you have Operator X v1.0 installed in the cluster. It came from a catalog source `quay.io/my-catalogs/my-catalog:master`. 
    10  This is the latest version of the X operator in the catalog source. Lets say Operator X is upgraded to v2.0. The catalog source image can be rebuilt
    11  to include the v2.0 version of the X operator and pushed to the same `master` tag. With catalog polling enabled, OLM will pull down the newer version 
    12  of the catalog source image and route service traffic to the newer pod. The existing subscription will seamlessly create the v2.0 operator and remove the old v1.0 one. 
    13  
    14  Each type of check for an updated catalog source is called an `updateStrategy`. Only one `updateStrategy` is supported at a time.
    15  `registryPoll` is a type of `updateStrategy` that checks an image registry for an updated version of the same tag. The `interval` defines
    16  the amount of time between each successive poll.  
    17  
    18  ## Example Spec
    19  Here is an example catalog source that polls `quay.io/my-catalogs/my-catalog:master` every 45 minutes to see if the image has been updated. 
    20  
    21  ```yaml
    22  apiVersion: operators.coreos.com/v1alpha1
    23  kind: CatalogSource
    24  metadata:
    25    name: catsrc-test
    26  spec:
    27    displayName: CatalogSource Test
    28    sourceType: grpc
    29    image: quay.io/my-catalogs/my-catalog:master
    30    updateStrategy:
    31      registryPoll:
    32        interval: 45m
    33  ```
    34  
    35  It is required for the catalog source to be sourceType grpc and be backed by an image for polling to work.  
    36  
    37  ## Caveats
    38  * The polling sequence is not instantaneous - it can take up to 15 minutes from each poll for the new catalog source pod to be deployed
    39  into the cluster. It may take longer for larger clusters. 
    40  * Because OLM pulls down the image every poll interval and starts the pod, to see if its updated, the updated catalog pod must be able to be
    41  scheduled onto the cluster. If the cluster is at absolutely maximum capacity, without autoscaling enabled, this feature may not work. 
    42  * OLM checks to see whether the container ImageID has changed between the old and new catalog source image when determining if an upgrade
    43  is in order. It does not actually parse the image content itself to check for later CSVs. If there is a bad upgrade to the catalog source image,
    44  simply overwrite the tag with another version and it will be pulled down, or delete and recreate the catalog source. 
    45  * The polling interval should be reasonably high to ensure the update functionality works as intended. Avoid intervals less than 15m.