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

     1   # Setting up a namespaced OLM for development
     2   
     3   * Disable global olm/catalog if the cluster is only for testing
     4      * spin `tectonic-alm-operator` down to 0
     5      * delete `alm-operator` and `catalog-operator` deployments from `tectonic-system`
     6   * Make any config customizations by editing `example-values.yaml`
     7   * Deploy a namespaced copy of OLM
     8  ```sh
     9  ./scripts/package_release.sh 1.0.0-custom custom-olm ./doc/install/example-values.yaml
    10  kubectl create ns olm-testing
    11  kubectl get secrets -n tectonic-system -o yaml coreos-pull-secret | sed 's/tectonic-system/olm-testing/g' | kubectl create -f -
    12  kubectl apply -f ./custom-olm
    13  ```
    14  
    15  * ALM config
    16      * `namespace` - namespace to run in 
    17      * `watchedNamespaces` - namespaces to watch and operate on
    18      * `catalog_namespace` - namespace that catalog resources are created in
    19      * ALM annotates the namespaces it's configured to watch and ignores namespaces annotated with another ALM instance
    20          * taking control of an existing namespace (i.e. if you've left the global olm running) may require manually editing namespace annotations
    21  
    22  * Catalog generation
    23      * Files in `deploy/chart/catalog_resources/<catalogname>` get collected into a configmap
    24      * on startup, catalog operator reads the configmap and writes out a CatalogSource pointing to it
    25          * hack because x-operator can't write out CatalogSource
    26      * short term: catalogsource -> configmap, no generation
    27      * medium term: stored in a seperate repo
    28      * longer term: something registry-like
    29  
    30  # Updating a Service and testing updates
    31  
    32  * Install the initial version 
    33      * Create an installplan with the initial version if it's already in the catalog
    34      * Create a CSV with the initial version if it's not in the catalog
    35  
    36  * Create the new version 
    37      * Copy old CSV
    38      * Edit fields to update version
    39          * name references (i.e. etcdoperator.0.5.6)
    40          * `replaces` field pointing to previous version
    41          * edit deployments
    42              * same name - gets patched
    43              * different name - gets created/deleted
    44          * use sha256 references
    45          * update any descriptions
    46          * update any references to CRDs that are required
    47          * update any permissions needed
    48  * Save new CSV and kubectl create it
    49  * Watch olm operator logs and verify state you want has happened
    50  
    51  
    52  # Updating a catalog entry
    53  
    54  * Once the CSV is verified as correct and updates work properly, add it to `catalog_resources`
    55      * do not overwrite the old one
    56  * Add any new CRDs to `deploy/chart/catalog_resources/<catalog>`
    57  * run `make update-catalog` to regen the catalog configmap
    58  * either apply the new configmap on its own and restart the catalog or, easier, just run:
    59  
    60  ```sh
    61  ./scripts/package_release.sh 1.0.0-custom custom-olm ./doc/install/example-values.yaml
    62  kubectl apply -f ./custom-olm
    63  ```
    64  
    65  * You can validate the update process by creating an `InstallPlan` with the previous version, letting it install, and then creating an `InstallPlan` with the updated version and verifying the update succeeds.
    66  
    67  
    68  # Example InstallPlan
    69  
    70  ```yaml
    71  apiVersion: app.coreos.com/v1alpha1
    72  kind: InstallPlan
    73  metadata:
    74    namespace: default
    75    name: olm-testing
    76  spec:
    77    clusterServiceVersionNames:
    78    - etcdoperator.v0.7.2
    79    approval: Automatic
    80  ```