<h1><img alt="Porter Logo" src="https://porter.sh/images/porter-logo.png?" width="100px" style="margin-right: auto; margin-left: auto;"/> PorterOps</h1>

PorterOps not only gives you a native, integrated experience for managing your bundles with Kubernetes but is the recommended way to automate your bundle pipeline with support for GitOps.

* Automate building and publishing bundles, when the bundle definition changes or new versions of images used by the bundle are available.
* Automatically deploy new versions of bundles.
* Isolated environments for running bundles in your organization, limiting access to secrets used by the bundles using namespaces and RBAC.
* Create and respond to events on your cluster to integrate bundles into your pipeline.

#### Why Porter Operator and not CNAB Operator?
PorterOps uses the Porter CLI, its configuration, storage, and accompanying ecosystem to manage bundles. It supports running any CNAB-compliant bundle, but this is not _the_ CNAB Operator. It has features specific to the Porter ecosystem and you cannot swap from using Porter to another tool.

Also our logo is super cute. 🐱

#### Why not BUCK?
Using an established operator library, which also integrates with the CNCF ArtifactHub, and is in a language that we are familiar with (Go vs. JavaScript) will enable rapid prototyping.

---

## User Experience

Our goal is to enable users to interact with the Porter Controller using the tools that they are familiar with. Some [components](#Components) can stand-alone, others build upon each other.

### I live my life one kubectl command at a time

[Porter Controller](#Porter-Controller) can be installed separately and does not depend on the other components. You can use kubectl to build, publish and execute bundles.

### I know kung-fu^^^^^^^Flux

Manage your bundles via the [Flux CLI](#Flux-CLI) and our [Flux Controller](#Flux-Controller).

### My operators have operators

Install the [PorterOps Package](#PorterOps-Package) from one of the major hubs and manage it using OLM.

### I'm all Porter, baby

Install PorterOps, and then build, publish and execute bundles through the familiar [Porter CLI](#Porter-CLI). Just give Porter a cluster and it takes care of the rest.

___

## Components

PorterOps is composed of a suite of components:

* Porter CLI
* Kubernetes Plugin
* Porter Operator
* Flux Controller
* Flux CLI
* PorterOps Package

### Porter CLI

In addition to the standard Porter CLI, adds commands for managing PorterOps:

* Install PorterOps
* Administer PorterOps (using OLM)
* Interact with the Porter Operator

Requires: [Kubernetes Plugin](#Kubernetes-Plugin), [Porter Operator](#Porter-Operator), [Flux Controller](#Flux-Controller), [PorterOps Package](#PorterOps-Package)

### Kubernetes Plugin

The Kubernetes Plugin for Porter supports retrieving secrets from Kubernetes for use by the Porter client and for use within bundles. It also enables Porter to use Kubernetes for storage.

Required by the [Porter CLI](#Porter-CLI)

### Porter Operator

The Porter Operator is a Kubernetes controller that builds, publishes and executes bundles. It is the main component of PorterOps. It uses the cnab-go Kubernetes driver to execute bundles on the cluster.

Requires: Nothing 🤘

### Flux Controller

The Flux Controller integrates Flux with the Porter Operator. This enables us to trigger Porter actions based on a git repository and OCI registry.

Requires: [Porter Operator](#Porter-Operator)

### Flux CLI

Adds support for interacting with the Porter Operator via the Flux CLI (fluxctl).

This replicates a subset of the functionality of the Porter CLI, It is a generic way of managing Porter resources, similar to how you can create Helm releases with fluxctl.

Fluxctl does not support plugins so it would be an upstream change.

Requires: [Porter Operator](#Porter-Operator), [Flux Controller](#Flux-Controller)

### PorterOps Package

PorterOps can be managed using Operator Lifecycle Manager, a framework to install, upgrade and manage Kubernetes operators. We can then list the PorterOps package on OperatorHub and its successor ArtifactHub.

Requires: [Porter Operator](#Porter-Operator), [Flux Controller](#Flux-Controller)

---

## Milestones

### MVP
The following is necessary to demonstrate the vision of PorterOps.

#### Porter Operator I
* Build, publish and execute bundles via kubectl.
* Use secrets stored in an external secret store supported by an existing Porter plugin.
* Store Porter's data off-cluster using a storage plugin, or on a Kubernetes volume.

This gives us a vanilla Kubernetes operator that anyone can use (not just with Flux). We still need the Porter plugins to give us the full feature set.

#### Porter CLI I
* Build, publish and execute bundles via porter.

This will significantly assist with testing which is why it's so early.

#### OLM Package I
* Install using OLM.

Again helps with testing, and early adopters/testers.

#### Flux Controller I
* Build, publish and execute bundles via GitOps.

This milestone demonstrates integration with Flux and using GitOps with Porter.

#### Flux Controller II
* Execute a bundle when a new version is available.

This is a critical usability milestone that really shows how PorterOps experience should be.

#### Kubernetes Plugin for Porter
* Use secrets defined on the cluster.
* Store Porter's data on the cluster.

This is a critical security and usability milestone, making it easier to store data securely than to do it in an insecure way. Secure by default. Until this point, the recommended way is to use the azure plugin or hashicorp plugin + encrypted volumes, which most devs won't bother with.

---

### Finish Line
If the MVP goes well, these round out PorterOps and make it easy for people to find and use.

#### Porter CLI II
* Install using porter.

Make it easy for Porter users to try out what we have built.

#### Flux CLI
* Build, publish and execute bundles via fluxctl.

Supports people who are more familiar with Flux than Porter, and get Flux to support bundles upstream. It could be dropped if necessary.

#### OLM Package II
* List on hubs for discovery.

Make it easier for people who aren't existing Porter users to find what we have made.

#### Porter Operator II
* Manage Porter's data through the Porter Operator.
* Immediately useful for cleaning up test data.
* Long term management of installations, and other Porter data. For example, pruning deleted installations after a period of time. Removing old revisions, large outputs, etc.

Day 2 operability.

#### Porter CLI III
* Use operability functionality in OLM from porter.

Encourage best practices by making the right way accessible directly from porter.