Installing Non Tekton Components through Tekton Operator

[sm43]

trafficstars

Operator provides multiple CRDs like TektonPipeline, TektonTrigger which on creation installs and manages the lifecycle of that respective component.

Example: TektonPipeline -> install and manages tektoncd/pipeline component

There is a Top level CRD TektonConfig which manages other CRDs depending on the profile. So, after operator installation if you create TektonConfig withall profile on Kubernetes platform. It will install

• TektonPipeline
• TektonTrigger
• TektonDashboard

Recently, couple of more components were added which are not enabled by default

• TektonChain
• TektonHub

We support 2 platform at present using the Extension Mechanism

• Kubernetes
• OpenShift When a release is done, release yaml for both platform are published.

For OpenShift, instead of TektonDashboard we ship TektonAddon CRD TektonAddon create additional resources for OpenShift platform only

• ClusterTasks
• Pipeline Templates
• ClusterTriggerBinding
• Pipelines As Code
• OpenShift Specific resources TektonAddon at present is not shipped with Kubernetes release yaml.

Configuration

Currently, each CRD has fields in spec for configuration which are later propagated by reconciler to their configmaps and other resources. As TektonConfig is a top level CRD, these are propagated from it to their respective CRDs.

Example:

apiVersion: operator.tekton.dev/v1alpha1
kind: TektonConfig
metadata:
   labels:
    operator.tekton.dev/release-version: 1.7.1
  name: config
spec:
  addon:
    enablePipelinesAsCode: true
    params:
    - name: clusterTasks
      value: "true"
    - name: pipelineTemplates
      value: "true"
    - name: communityClusterTasks
      value: "true"
  config: {}
  dashboard:
    readonly: false
  hub: {}
  params:
  - name: createRbacResource
    value: "true"
  pipeline:
    default-service-account: pipeline
    disable-affinity-assistant: true
    disable-creds-init: false
    enable-api-fields: stable
    enable-custom-tasks: false
    enable-tekton-oci-bundles: false
    params:
    - name: enableMetrics
      value: "true"
    require-git-ssh-secret-known-hosts: false
    running-in-environment-with-injected-sidecars: true
    scope-when-expressions-to-task: false
  profile: all
  pruner:
    keep: 100
    resources:
    - pipelinerun
    schedule: 0 8 * * *
  targetNamespace: openshift-pipelines
  trigger:
    default-service-account: pipeline
    enable-api-fields: stable

Platform specific configurations are passed through params, for example

    params:
    - name: enableMetrics
      value: "true"

This is passed as param on OpenShift so that it will not appear on Kubernetes platform. But this makes the UX inconsistent. Issue

Need Improvements:

• Pipelines As Code which is a non-tekton project is currently installed as an Addon but as it is getting bigger, it requires its own CRD and reconciler to manage its installation and lifecycle.

Proposal:

• We would like to add a Separate CRD and Reconciler to manage Pipelines As Code So, if user create a CR for example PipelinesAsCode, it will be installed As It’s a non Tekton project, it will document as it is not supported by Tekton Community It will be optional to install We can even decide to generate more "release.yaml", for example one with only tektoncd upstream component, etc..

• Adding a platform specific section in TektonConfig To make UX better, we would like to add a OpenShift Section TektonConfig will look as

  apiVersion: operator.tekton.dev/v1alpha1
  kind: TektonConfig
  metadata:
     labels:
      operator.tekton.dev/release-version: 1.7.1
    name: config
  spec:
    trigger: {}
    dashboard: {}
    pipeline:
      default-service-account: pipeline
      disable-affinity-assistant: true
      disable-creds-init: false
      …
  
    openshift:
      enableMonitoring: true
    gcp: {}
  

  • In future we could have section for other cloud provider
  • On kubernetes, the CR will have openshift section mentioned but will not affect
  • We could even "warn" the user if there is an openshift key present (that will be ignore) using the webhook

[sm43]

cc @vdemeester @dibyom @afrittoli @abayer @lbernick @jerop

[dibyom]

As It’s a non Tekton project, we can be documented it is not supported by Tekton Community It will be optional to install

Sounds good

We can even decide to generate more "release.yaml", for example one with only tektoncd upstream component, etc..

Yeah, a tekton only release and a tekton+extensions release makes sense to me

Adding a platform specific section in TektonConfig

Maybe we can nest that under an extensions or platform section. So we can platforms.openshift, platforms.kubernetes, (platforms.some-other-platform in the future?) What do you think?

We could even "warn" the user if there is an openshift key present (that will be ignore) using the webhook

this also sounds like a good idea.

Thanks @sm43 I like the proposal. Is the idea that the CR/reconciler for PAC also resides in this repo or is that already in a separate repo that is pulled in?

[sm43]

As It’s a non Tekton project, we can be documented it is not supported by Tekton Community It will be optional to install

Sounds good

We can even decide to generate more "release.yaml", for example one with only tektoncd upstream component, etc..

Yeah, a tekton only release and a tekton+extensions release makes sense to me

Adding a platform specific section in TektonConfig

Maybe we can nest that under an extensions or platform section. So we can platforms.openshift, platforms.kubernetes, (platforms.some-other-platform in the future?) What do you think?

@dibyom yep. this could also be a way, would be more clear to user. 👍🏽

We could even "warn" the user if there is an openshift key present (that will be ignore) using the webhook

this also sounds like a good idea.

Thanks @sm43 I like the proposal. Is the idea that the CR/reconciler for PAC also resides in this repo or is that already in a separate repo that is pulled in?

the initial thought was to keep it in tektoncd/operator repository as it is dependent on Pipelines components so it makes development easy and release would also be a bit easier, otherwise for release there would be dependency on another repository. we could keep them in a separate directory like contrib where we keep non-tekton components

there is another way too, where we could keep the CRD and Reconciler in PAC repository so basically PAC has its own operator and we just import the CRD and the reconciler as dependency in main.go in tektoncd/operator for the release.

WDYT? 🙃

[dibyom]

Yeah either option sounds fine to me. I brought this up in the Community WG last week. Might be worth getting feedback from others in the Gov board as well (@afrittoli @vdemeester @jerop @priyawadhwa)

[priyawadhwa]

Maybe we can nest that under an extensions or platform section. So we can platforms.openshift, platforms.kubernetes, (platforms.some-other-platform in the future?) What do you think?

+1, this sgtm!

[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.

[sm43]

this has been implemented. so now we have OpenShiftPipelinesAsCode CR which is only installed for openshift platform it is not packaged with the kubenetes platform release, also not included in the build too. we have a section in TektonConfig for platforms and openshift is included under it. as this is completed closing the issue.