# 3 Minute Rukpak Pitch

## Background

### What is the Operator-Lifecycle-Manager (OLM)?

OLM is a tool designed around installing, upgrading, and removing operators from a Kubernete's cluster.

### Why is OLM changing its APIs

OLM was developed alongside the implementation of [CustomResourceDefinitions](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/). Many of the design decisions made in the early stages of OLM's development were made based on the communities best guess in terms of how CRDs would evolve.

CRDs have now stabalized, and OLM can offer a much better user experience by deprecating the existing APIs and introducing tightly focused controllers that act as building blocks for a more complete user experience. These projects can be used independently of one another, are applicable to a variety of usecases, and are extendable by the community.

There are currently two components that are available upstream for outside contributions:
1. The [RukPak](github.com/operator-framework/rukpak/) Project
2. The [Deppy](https://github.com/operator-framework/deppy/) Project

Let's discuss both of these solutions

## RukPak

RukPak is actively under development and will be used to manage the installation, upgrades, and removal of a set of manifests, which we refer to as a bundle. Each bundle represents a version of "your thing" that you want RukPak to install.

There are three concepts that are core to the RukPak experience:
1. The **Bundle**, which represents a collection of manifests that make up "your thing"
2. The **BundleDeployment**, which "points" to a bundle and causes the manifests described within to be installed on cluster.
3. The **Provisioner**, which is an oncluster controller responsible for "unpacking" bundles and "deploying" bundleDeployment on cluster.

Let's dive into each of these topics in greater depth.

### Bundle CRD

Bundles are a packaging format that represent "the stuff" that you need to install. RukPak is pluggable, so a provisioner could be built for any format type. For example, the "Plain Provisioner" expects a bundle to exist in the following format:

manifests
├── namespace.yaml
├── cluster_role.yaml
├── role.yaml
├── serviceaccount.yaml
├── cluster_role_binding.yaml
├── role_binding.yaml
└── deployment.yaml

### BundleDeployment CRD

kubectl apply -f -<<EOF
apiVersion: core.rukpak.io/v1alpha1
kind: BundleDeployment
metadata:
  name: prometheus
spec:
  # Used to identify which provisioner should install the manifests
  provisionerClassName: core-rukpak-io-plain
  template:
    metadata:
      labels:
        app: prometheus
    spec:
      # Used to identify which provisioner should unpack the bundle
      provisionerClassName: core-rukpak-io-registry
      source:
        type: image
        image:
          ref: quay.io/operatorhubio/prometheus:v0.47.0--20220325T220130
EOF

### Provisioners

RukPak will provide a set of default provsioners. Existing provisioners include:
- A [Plain Provisioner](https://github.com/operator-framework/rukpak/blob/c0103c7b358732424ebb7b5aee152c1fff0c240f/docs/provisioners/plain.md) which supports unpacking bundles from images, directories in git, an http endpoint, a configMap
- A [Helm Provisioner](https://github.com/operator-framework/rukpak/blob/c0103c7b358732424ebb7b5aee152c1fff0c240f/docs/provisioners/helm.md) which installs helm+v3 bundles onto a cluster and then install the referred helm chart on the cluster.
- A [Registry Provisioner](https://github.com/operator-framework/rukpak/blob/c0103c7b358732424ebb7b5aee152c1fff0c240f/docs/provisioners/registry.md) which is backwards compatible with the existing OLM packaging format.

Users will be allowed to develop and share their own provisioners, allowing individuals to install, upgrade, and lifecycle "bundles" from any storage format.

## Deppy

Deppy is early in it's development process and is being designed to act as a generic SAT Solver. At a high level, Deppy will allow users to:
- Provide a set of entities that can fulfill certain constraints.
- Provide a set of constraints that Deppy will attempt to satisfy with the set of entities.

In the OLM usecase, Deppy will be used to satisfy OLM's package manager requirements

>User: “I want version v1.2.3 of operator foo”
>Deppy: "That can be fulfilled by operator-foo.v1.2.3

>User: “I want version v1.2.4 of operator foo”
>Deppy: “Operator foo v1.2.3 does not exist”

>User: “I want version v1.2.5 of operator foo”
>Deppy: “Operator foo depends on operator bar v4.5.6”

In practice, Deppy could be used by any project to satisfy any constraint evaluation against a set of entities, making it applicable to projects outside of OLM.

## Links to get involved

- The [#deppy-dev Slack Channel](https://kubernetes.slack.com/archives/C045L6WK27N)
- The [#rukpak-dev Slack Channel](https://kubernetes.slack.com/archives/C045L6WK27N)

## Link to pitch