Epic Goal

Migrate from pure upstream operator to our own OpenShift Pipelines Operator

Why is this important?

• As time goes, we want to add more OpenShift specific / our own opinion into the operator. This can lead to friction upstream (pushing OpenShift specific things) as well as confusion in the support model, …
• 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
• OpenShift being the major platform that “supports operators”, we may want to heavily focus on this and are not really doing a great job at supporting plain kubernetes upstream.
• The code base is also a little bit weird / intimidating to work with
• With "features" like OpenShift Console Dynamic plugin, it make even more sense to split the OpenShift specific part and the upstream one.
• In the light of "Service First", it makes even more sense to have our own, fully-controlled operator

Scenarios

N/A, from the user perspective, nothing would change.
From the development perspective, upstream would be a "thin" layer that only packages upstream component, and openshift-pipelines/operator would be where we add our opinion, UIs, components, …

Acceptance Criteria (Mandatory)

• CI - MUST be running successfully with tests automated
• Release Technical Enablement - Provide necessary release enablement details and documents.
• Downstream operator is built on top of openshift-pipelines/operator instead of tektoncd/operator

Dependencies (internal and external)

N/A

Previous Work (Optional):

• https://hackmd.io/LcdaZ004RwSQ7X5c6LR-YQ

Open questions::

Done Checklist

• Acceptance criteria are met
• Non-functional properties of the Feature have been validated (such as performance, resource, UX, security or privacy aspects)
• User Journey automation is delivered
• Support and SRE teams are provided with enough skills to support the feature in production environment