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

QA - Change the default behaviour of Pipelines/Task Timeout triggers Pod Deletion

XMLWordPrintable

    • 3
    • False
    • Hide

      None

      Show
      None
    • False
    • Hide
      Included in 1.21: https://github.com/openshift/openshift-docs/pull/100818

      If Feature flag "keep-pod-on-cancel" is set to true then pods corresponding to TaskRun will be not be deleted when TaskRun Times Out. Earlier pod was retained only if it taskrun was canceled.
      Show
      Included in 1.21: https://github.com/openshift/openshift-docs/pull/100818 If Feature flag "keep-pod-on-cancel" is set to true then pods corresponding to TaskRun will be not be deleted when TaskRun Times Out. Earlier pod was retained only if it taskrun was canceled.
    • Bug Fix
    • Done
    • +

      Epic Goal

      By default, If a TaskRun runs longer than its timeout value, the pod associated with the TaskRun will be deleted. This means that the logs of the TaskRun are not preserved. The deletion of the TaskRun pod is necessary in order to stop TaskRun step containers from running.

      We already have keep-pod-on-cancel, but this only applies when the Pipeline/Task is cancelled. We should take into account this feature-flag, and if true, we should respect it when the Pipeline/Task times-out, a.k.a. not deleting the Pod.
      Use case

      Why is this important?

      When there is a timeout, the user might want to inspect the Pod (or at least look at the logs) to understand what happened ; especially if the user can already do this when he/she cancels the Pipeline/Task.

      Scenarios

      N/A

      Acceptance Criteria (Mandatory)

      • CI - MUST be running successfully with tests automated
      • When keep-pod-on-cancel is set to true, a Pipeline or Task that times out shouldn't delete the Pod

      Dependencies (internal and external)

      1. ...

      Previous Work (Optional):

      Open questions::

      Done Checklist

      • Acceptance criteria are met
      • Non-functional properties of the Feature have been validated (such as performance, resource, UX, security or privacy aspects)
      • User Journey automation is delivered
      • Support and SRE teams are provided with enough skills to support the feature in production environment

              Unassigned Unassigned
              vdemeest Vincent Demeester
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Created:
                Updated: