Uploaded image for project: 'Docs for Red Hat Developers'
  1. Docs for Red Hat Developers
  2. RHDEVDOCS-6103

DOC: need to tune tekton webhooks from TektonConfig

XMLWordPrintable

    • 3
    • Documentation (Ref Guide, User Guide, etc.), User Experience
    • Hide
      Adds webhook configuration options(FailurePolicy, TimeoutSeconds, SideEffects) to tektonConfig additional options
      Show
      Adds webhook configuration options(FailurePolicy, TimeoutSeconds, SideEffects) to tektonConfig additional options
    • ---
    • ---

      Story (Required)

      As a administrator of tekton trying to tune the validating webhook I want to be able to change fields like 'timeoutSeconds' and 'failurePolicy' via my TektonConfig

       

      Background (Required)

      During the triage of https://issues.redhat.com/browse/SRVKP-4427 where intermittent calls to the "validation.webhook.pipeline.tekton.dev"

      would timeout after 10 seconds, even when we bumped min replicas to as high as 6 with the horizontal pod autoscaler, we explored trying to tune those timeout and failure policy settings, but updating the TektonInstallerSet was the only path.

      That was problematic for several reasons:

      • manual edit of an object that have to be repeated after upgrades or recycling of the operator is untenable in a production environment managed by gitops.  It needs to be udpated
      • creating k8s json patches where you add fields to arbitrary array entries is also very difficult if not impossible

       

      A first class way of tuning this is needed.

      Out of scope

      <Defines what is not included in this story>

      Approach (Required)

      <Description of the general technical path on how to achieve the goal of the story. Include details like json schema, class definitions>

      Adding a map of Webhooks to AdditionalOptions seems to make the most sense.

      HorizontalPodAutoscalers are already there.

      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>

      INVEST Checklist

      Dependencies identified

      Blockers noted and expected delivery timelines set

      Design is implementable

      Acceptance criteria agreed upon

      Story estimated

      Legend

      Unknown

      Verified

      Unsatisfied

      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

              mramendi Mikhail Ramendik
              mramendi Mikhail Ramendik
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

                Created:
                Updated:
                Resolved: