---
# System prepended metadata

title: OLM integration proposal

---

---
title: "Support Operator Lifecycle Manager (OLM)"
authors: [ "Andy Goldstein <angoldst@redhat.com>", "Joao Pereira <joaod@vmware.com>" ]
status: "draft"
approvers: [ "Dmitriy Kalinin <dkalinin@vmware.com>", "Praveen Rewar <prewar@vmware.com>", "Neil Hickey <nhickey@vmware.com>"]
---

# Support Operator Lifecycle Manager (OLM)

## Problem Statement
With the growing utilization of Kubernetes as the platform of choice to run workloads in the cloud, multiple solutions were developed to help end users install these workloads. The majority of them were created to solve a specific use case and after that grew due to their users input to become more generic, starting to overlap with each other.

Some time back Carvel decided to create a Packaging API that is generic enough to allow our users to install and manage the lifecycle of their applications.

Operator Lifecycle Manager is another tool that is used to install, manage, and upgrade Operators on a cluster.

After some research we concluded that some of the concepts used in both these tools overlap and we could create some synergy between them. By doing this we would be able to leverage the machinery built in these tools to make a better experience to all users.

## Terminology / Concepts
OLM - Operator Lifecycle Manager

Operator - Method for application packaging and deployment that extends Kubernetes' capabilities to manage more complex, stateful workloads.

CatalogSource - Represents a store of metadata that OLM can query to discover and install operators and their dependencies.

Channel - Concept that allows the operator author a means to specify a set of update streams for your operator.

## Proposal
In this proposal we will discuss how can we enhance the current Carvel APIs to support some of the concepts that exist in OLM.

### Goals and Non-goals
#### Goals
- Enhance the Packaging API to support OLM concepts
- Create a highlevel design of the workflow of Catalogs


#### Non-goals
- Be prescriptive in the implementation details

### Specification / Use Cases
These are the following use cases that we want to add to the Packaging API

**As an** Operator User
**I want to** provide my Catalog to kapp-controller
**So that** I can install my operators

#### Proposed changes to the CRD's
##### PackageRepository
```yaml=
apiVersion: packaging.carvel.dev/v1alpha1
kind: PackageRepository
metadata:
spec:
  fetch:
    # pulls the OLM catalog of operators
    olmCatalog:
```


#### Use Case: Install Catalog in cluster
**Given** I have a Catalog with 1 operator

**When** I add the following the following yaml to my cluster
```yaml=
apiVersion: packaging.carvel.dev/v1alpha1
kind: PackageRepository
metadata:
  name: postgres-operator-catalog
  namespace: my-ns
spec:
  fetch:
    olmCatalog:
      image: my.registry.io/my-operator-catalog
      path: config/
```
**Then** I should see in my cluster
```yaml=
apiVersion: data.packaging.carvel.dev/v1alpha1
kind: Package
metadata:
  name: postgresql.olm.operatorframework.io.5.4.2
  namespace: my-ns
  labels:
      olm.channel: "stable,v5"
spec:
  refName: postgresql.olm.operatorframework.io
  version: 5.4.2
  template:
    spec:
      fetch:
      - imgpkgBundle:
          image: registry.tkg.vmware.run/tkg-fluent-bit@sha256:...
      template:
      - ytt:
          paths:
          - config/
      - kbld:
          paths:
          # - must be quoted when included with paths
          - .imgpkg/images.yml
          - "-"
      deploy:
      - kapp: {}
```


#### Install postgresql operator in the cluster
**Given** I added the Catalog to the cluster

**When** I add the following yaml to the cluster
```yaml=
apiVersion: packaging.carvel.dev/v1alpha1
kind: PackageInstall
metadata:
  name: latest-postgres
  namespace: my-ns
spec:
  serviceAccountName: default-ns-sa
  packageRef:
    refName: postgresql
```
**Then** The latest version of the postgresql operator should be installed in `my-ns`

#### Install particular version of postgresql operator

**Given** I added the Catalog to the cluster

**When** I add the following yaml to the cluster
```yaml=
apiVersion: packaging.carvel.dev/v1alpha1
kind: PackageInstall
metadata:
  name: specific-postgres
  namespace: my-ns
spec:
  serviceAccountName: default-ns-sa
  packageRef:
    refName: postgresql
    versionSelection:
       constraints: "2.5.6"
```
**Then** The version 2.5.6 of the postgresql operator should be installed in `my-ns`


#### Install particular version of postgresql operator restricted by channel

**Given** I added the Catalog to the cluster

**When** I add the following yaml to the cluster
```yaml=
apiVersion: packaging.carvel.dev/v1alpha1
kind: PackageInstall
metadata:
  name: latest-stable-postgres
  namespace: my-ns
spec:
  serviceAccountName: default-ns-sa
  packageRef:
    refName: postgresql
    versionSelection:
       label: olm.channel=stable
```
**Then** The latest version of the postgresql operator in the `stable` channel should be installed in `my-ns`.

### Other Approaches Considered
_Mention of other reasonable ways that the problem(s)
could be addressed with rationale for why they were less
desirable than the proposed approach._

## Open Questions
- What would the content of fetch and template phase would look like for the created packages

## Answered Questions
_A list of questions that have been answered._