TektonConfig CRD - Capability to add pipeline and triggers namespace as dashboard properties

[srisek]

Feature request

Currently by default the dashboard install using the operator is setting the default namespace for tekton pipelines and tekton triggers to 'tekton-pipelines' . In certain use cases if the operator is installing tekton resources in a different namespace the dashboard is failing to read the pipeline and triggers config due to the below setting.

args: '--port=9097'

• '--logout-url='
• '--pipelines-namespace=tekton-pipelines'
• '--triggers-namespace=tekton-pipelines'
• '--read-only=true'
• '--log-level=info'
• '--log-format=json'
• '--namespace='
• '--stream-logs=true'

It would we helpful if all these options can be parameterized as dashboard properties in the TektonConfig CRD while installing and setting properties for dashboard.

Currently it supports only readonly mode and external logs feature as of now https://github.com/tektoncd/operator/blob/main/pkg/apis/operator/v1alpha1/tektondashboard_types.go#L88

Use case

If we want to install tekton components in a different namespace other than the default namespace 'tekton-pipelines'.

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

[jkandasa]

/lifecycle frozen

[T3-git]

I'm interested in working on this issue and would like to confirm whether it requires a TEP. @jkandasa, @vdemeester, could you please advise if a TEP is needed for this? I believe it might be, but I wanted to double-check with you both.

[T3-git]

/assign

[AlanGreene]

fyi, this is already supported today via the options field: https://tekton.dev/docs/operator/tektonconfig/#additional-fields-as-options

You can set any of the Dashboard deployment's args using that approach.

e.g.

apiVersion: operator.tekton.dev/v1alpha1
kind: TektonConfig
metadata:
  name: config
spec:
  dashboard:
    options:
      deployments:
        tekton-dashboard:
          spec:
            template:
              spec:
                containers:
                  - name: tekton-dashboard
                    args:
                      - "--pipelines-namespace=my-custom-namespace"

This is available since Operator v0.68.0

[T3-git]

@AlanGreene forgive I am new to this project, is there still something to be implemented? I believe no right?

[AlanGreene]

I'll let the @tektoncd/operator-maintainers answer that as I'm not sure if there are advantages from the Operator point of view to having these be predefined fields rather than in options or if they're essentially equivalent. From the Dashboard point of view it doesn't matter which approach is used.

[T3-git]

Waiting for reply from operator-maintainers.

[piyush-garg]

We are moving to options field in the future, and will be deprecating the other way of providing every flag in spec.

You can get the details of the options field here https://github.com/tektoncd/operator/blob/main/docs/TektonConfig.md#additional-fields-as-options

The requirement stated in this issue can be achieved by options field as provided by @AlanGreene I think we are good to close this. Thanks

[nitang22]

Since the operator installs all the tekton ressources in the defaultTargetNamespace would it make more sense to put this as default in the config? Otherwise the defaultTargetNamespace is useless for dashboard.