build
build copied to clipboard
shipwright-io
Pruning of BuildRun Objects
openshift build v1 api today has fields that allow on a per build config basis the maximum amount of builds to keep in etcd.
Tekton has an unimplemented open features for this: https://github.com/tektoncd/pipeline/issues/1334 , https://github.com/tektoncd/pipeline/issues/1302 , and those also reference the upstream alpha feature around TTL for jobs/pods
build v2 tie in to the upstream tekton solution seems the long term solution
it that takes too long, do they want to build something akin to what exists in the build v1 controller for build v2?
related code in build v1 https://github.com/openshift/openshift-controller-manager/blob/071b34b64ea82e87014bccb2ed14f6c2cf4ac9fe/pkg/build/controller/common/util.go#L40
Upstream Tekton supports manual pruning of TaskRun/PipelineRun via the tkn cli. Perhaps we can take a similar approach with our cli.
Another alternative is to control this per namespace. Kubernetes supports resource quotas( see https://kubernetes.io/docs/concepts/policy/resource-quotas/#object-count-quota ) for CRDs. However I dont think this approach is ideal for this issue. I think this needs to be worked on Tekton side, I will ask the Tekton community inside IBM for more information.
Another alternative is to control this per namespace. Kubernetes supports resource quotas( see https://kubernetes.io/docs/concepts/policy/resource-quotas/#object-count-quota ) for CRDs. However I dont think this approach is ideal for this issue. I think this needs to be worked on Tekton side, I will ask the Tekton community inside IBM for more information.
I'll be curious what you hear on the Tekton/IBM side (and who precisely, as I may have interacted with some of the folks you talk to).
My high level interpretation over the last year of so:
- they defer to manual / outside of the project efforts for this a la what @adambkaplan noted above
- there was some hope a while back on working off of the upstream k8s efforts around Job pruning, but that has fizzled / now worked out (both upstream k8s and tekton)
@gabemontero yes, from Tekton ( mainly communicating with https://github.com/afrittoli ) side what they have is external ways for deleting existing resources, e.g.:
- nightly CIs ( e.g. cronjob )
- tkn provides that feature to delete resources ( e.g. we could reuse their go pkg for deleting )
but nothing related to a mechanism for pruning resources based on some threshold that was reached ( e.g. we exceed 100 taskruns per namespace ) .
We should continue using this issue to provide more ideas on how to achieve this for us.
