Eliminate the explicit dependency between components enforced by operator

[nikhil-thomas]

Description

At present, operator enforces an explicit dependency between components during installation and upgrades. For example, TektonTrigger reconciler will install Tektoncd Triggers only if the operaotor can verify that Tektoncd Pipelines is already installed by the operator (checks for TektonPipeline instance status). In the case of OpenShift, TektonAddon installation waits till TektonPipeline and TektonTriggers are installed.

These explicit blocking of component installation creates unnecessary delays in the installation process. We loose the oportunity to run each reconciler in a truly parallel sense.

In my opinion, if we eliminate this dependency and move such validations in to a common point, we can make the operator faster and the ux more smooth.

For example, we can move validations to the end of TektonConfig reconciler from various other reconcilers. In addition, TektonConfig reconciler is the one who is aware of "Profiles" or the list of components being installed.

Challenges and Possible Solutions to Tackle them

1. TektonAddon (in OpenShift) has a real dependency on Pipelines and Triggers as operator won't be able to create ClusterTasks and ClusterTriggerBindings from TektonAddon if Pipeline and Triggers are not installed

One way to handle this situation will be to move the installation of "Addons" like clusterTasks to the "PostReconcie" of appropriate reconciler. For example, we can make OpenShift extension for TektonPipeline reconciler handle installation of ClusterTasks.

[nikhil-thomas]

cc @concaf

[concaf]

I think that a prerequisite before starting this would be to analyze all the components on a case-to-case basis on what their behavior is when the dependency is not present (and possibly establish a project wide consensus/standard on how cases like this (dependency missing) are handled)

[tekton-robot]

Issues go stale after 90d of inactivity. Mark the issue as fresh with /remove-lifecycle stale with a justification. Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with /close with a justification. If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.

/lifecycle stale

Send feedback to tektoncd/plumbing.

[tekton-robot]

Stale issues rot after 30d of inactivity. Mark the issue as fresh with /remove-lifecycle rotten with a justification. Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with /close with a justification. If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.

/lifecycle rotten

Send feedback to tektoncd/plumbing.

[tekton-robot]

Rotten issues close after 30d of inactivity. Reopen the issue with /reopen with a justification. Mark the issue as fresh with /remove-lifecycle rotten with a justification. If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.

/close

Send feedback to tektoncd/plumbing.

[tekton-robot]

@tekton-robot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity. Reopen the issue with /reopen with a justification. Mark the issue as fresh with /remove-lifecycle rotten with a justification. If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.

/close

Send feedback to tektoncd/plumbing.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.