# OpenShift Pipelines operator

###### tags: `tektoncd` `openshift-pipelines` `pipeline` `operator`

# Summary

This explore the different reasons for having our own `openshift-pipelines/operator` based off of `tektoncd/operator` instead of relying completely on `tektoncd/operator`.
This also explore what shape could the "new" API have as well as how we would have to handle the migration.

# Challenges

Today, we are facing a few challenges by having everything upstream.

- There is possible "friction" when we want to include OpenShift specific components, such as `pipelines-as-code`. As time will go, there will be more and more cases around this.
- Because we share the exact same API with upstream, we end up with issues like https://github.com/tektoncd/operator/issues/759 (inconstistent API)
- Some feature are enabled for kubernetes but not openshift target and vice-versa
- Upstream openshift target is not tested against an OpenShift cluster at all
- OpenShift being the major platform that "supports operators", we may want to heavily focus on this
- Little to no contributions outside of Red Hat

# Proposals

The TL;DR is : OpenShift Pipelines source of truth is going to be [`openshift-pipelines/operator`](https://github.com/openshift-pipelines/operator).

- `openshift-pipelines/operator` becomes the source of truth for the OpenShift Pipelines Operator
- an upstream build (aka not using internal process, nor published on registry.redhat.io) could be published as OpenShift Pipelines on OKD
- `tektoncd/opeartor` is only the source of truth for upstream Tekton Operator (on operator community hub)
- `tektoncd/operator` doesn't support `openshift` as a target anymore

What we will explore here is also, what are the next step and what [`tektoncd/operator`](https://github.com/tektoncd/operator) becomes.

## Proposal A

We follow `serverless-operator` model (loosely).

- `openshift-pipelines/operator` uses `tektoncd/operator` as a "code" dependency
- `openshift-pipelines/operator` uses upstream CRDs (`TektonPipeline`, …) for upstream component as well as its own (for `PipelineAsCode`, custom task, custom resolvers, …)
- the main CRD is `OpenShiftPipelineConfig`, which is similar to `TektonConfig` but with the shape we want our OpenShift Pipeline Configuration API to be
- `openshift-pipelines/operator` releases are synced with the product release

Pros:
- We own *some* CRDs (mainly the entrypoint one)

Cons:
- Duplicate work "warning"
- We depend on upstream releases (code)
- Two repository to maintain for the team
- Extra work (as today), releasing the operator, publishing on community operatorhub, helm chart, …

## Proposal B

- `openshift-pipelines/operator` uses `tektoncd/operator` as a "runtime" dependency but *runs* the controller
- `openshift-pipelines/operator` reconciler (for openshift-pipelines object) create `tektoncd/operator` CR from it
e.g. From `TektonConfig` config, we create a `TektonPipeline` object, as well as other internal CR (`OSPSomething`)
- `tektoncd/operator` moves to be *super* extensible (aka, anything can be overriden easily through the CR)
- that way, we give a lot of room for upstream user to do whatever they want
- and for OSP we control this as we only expose, through our objects, what we want

Pros:
- we own all our CRDs while still using upstream
- upstream becomes super extensible and is "liberated" from OpenShift

Cons:
- We depend on upstream releases (code)
- Duplicate work "warning" (less that Proposal B, but still…)
- Two repository to maintain for the team
- Extra work (as today), releasing the operator, publishing on community operatorhub, helm chart, …

## Proposal C

- `openshift-pipelines/operator` doesn't use `tektoncd/operator`
- we move `tektoncd/operator` into maintainance mode and actively looking for outside of Red Hat contributors to not deprecate it (otherwise, we deprecate it)
- `openshift-pipelines/operator` starts as a fork of `tektoncd/operator` and we evolve it *solely* for OpenShift purpose
- removing kubernetes target
- removing non openshift specifics

Pros:
- One repository to maintain
- Full ownership of the project
- Little to no work upstream (*or* we'll get some help)

Cons:
- Disengaging from upstream on "operator"
(reducing our "contribution" count as.. this is the project we are the most active on)

## Decision

*Need to be discussed*.

## Benefits

- We control the main APIs
- We can include any component we want (not possible upstream)
- Reduces friction with upstream
- We can version it the same way we version our product
This is less confusing for the users.
- Tracking issues will be less confusing upstream
- it's related to openshift pipelines (OCP or OKD), it goes to `openshift-pipelines/operator` (or on our board)
- it's related to the tekton operator, it goes to `tektoncd/operator`
- Clearer separation of concern (code).

# Migration

This proposal comes with a rename of the main object the users interact with. This means we will need a migration path for users to go from `TektonConfig` to `OpenShiftPipelineConfig`.

- If both `TektonConfig` and `OpenShiftPipelineConfig` are present, we *always* use `OpenShiftPipelineConfig`
- and we generate an "error" event on some namespace (openshift-operators ?)
- If `TektonConfig` is present but no `OpenShiftPipelineConfig`, we create an `OpenShiftPipelineConfig` from it