Uploaded image for project: 'OpenShift Pipelines'
  1. OpenShift Pipelines
  2. SRVKP-4505

replace opc cli tekton results offering with new plugin from Sayan Biswas

XMLWordPrintable

    • False
    • None
    • False

      Summary

      As a Konflux maintainer trying to support the use of tekton results I want the cli code hosted in a repo of one of the projects github orgs

      As a Tekton user, and in particular a Tekton User who wants to interact with Tekton Results, I want to be able to interact in a way that mirrors my user experience using kubectl/oc/tkn when accessing the setting on the tekton api object, or the logs from underlying pods generated by Tekton.

      Background (Required)

      Sayan developed the plugin out of his github org to accelerate delivery to the pipeline service team and its need to support konflux

      https://github.com/sayan-biswas/kubectl-tekton

       

      It has proven invaluable in eliminating the complexities of interacting with the database and storage where tekton run objects settings and their underlying logs.

       

      It provides user experience on par with what you get with tkn when you log into a cluster and access tekton object and underlying pod logs.

      Out of scope

       

      Approach (Required)

      Per a Apr 4 2024 refinement call between rh-ee-sabiswas rh-ee-kbaig and gmontero@redhat.com agreement was reached amongst us that Sayan's plugin is superior to the existing opc support for results.

      In particular, if you look at the help for `opc results` and the confirguration section:

      Environment Variables:
          TKN_RESULTS_SSL_ROOTS_FILE_PATH: Path to local SSL cert to use.
          TKN_RESULTS_SSL_SERVER_NAME_OVERRIDE: SSL server name override (useful if using with a proxy such as kubectl port-forward).

      Config:
          A config file may be stored in `~/.config/tkn/results.yaml` to configure the CLI client.

          Fields:
          - address: Results API Server address
          - service_account: When specified, the CLI will first fetch a bearer token
                             for the specified ServiceAccount and attach that to Result API requests.
              - namespace: ServiceAccount namespace
              - name: ServiceAccount name
          - token: Bearer token to use for API requests. Takes priority over service_account.
          - ssl: SSL connection options
              - roots_file_path: Path to a certificate to include in the cert pool. Useful for adding allowed self-signed certs.
              - server_name_override: For testing only. Sets the grpc.ssl_target_name_override value for requests.
          - portforward: enable auto portforwarding to tekton-results-api-service when address is set and portforward is true, tkn-results will portforward tekton-results-api-service automatically

      Sayan's plugin instead

      • leverages the user's local kubeconfig like oc/kubectl/tkn does.  
      • It can also find the default for those settings, vs the user having to find and specify them
      • his version also has nice / extra pagination features, as the amounts of entries stored in the database can be far more numerous than what users are typically used to when accessing etcd and the size control around etcd that occurs with various pruners provided by various k8s add on features (like tekton's pruner or the openshift build pruner for example)

      Dependencies

      <Describes what this story depends on. Dependent Stories and EPICs should be linked to the story.>

       

      Acceptance Criteria  (Mandatory)

      <Describe edge cases to consider when implementing the story and defining tests>

      <Provides a required and minimum list of acceptance tests for this story. More is expected as the engineer implements this story>

       

      Done Checklist

      • Code is completed, reviewed, documented and checked in
      • Unit and integration test automation have been delivered and running cleanly in continuous integration/staging/canary environment
      • Continuous Delivery pipeline(s) is able to proceed with new code included
      • Customer facing documentation, API docs etc. are produced/updated, reviewed and published
      • Acceptance criteria are met

            Unassigned Unassigned
            gmontero@redhat.com Gabe Montero
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated: