Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

adds auto-prune per namespace #410

Merged
merged 2 commits into from
Oct 8, 2021

Conversation

pradeepitm12
Copy link
Contributor

@pradeepitm12 pradeepitm12 commented Sep 16, 2021

This adds auto-pruning of taskrun and pipeline run per namespace
configured specifically.
adding unique schedule create a new cronjob in the annotated
namespace.
The default behaviour will persist, on top of it now user can
annotate a namespace with unique pruning configuration.
If user configures a unique schedule value by annotating a ns
a new cron job in that namespace will be created.

Auto purning is now enabled by default for default configurations
from tektonconfig.

Annotations introduced with this pr
- "operator.tekton.dev/prune.skip"
- "operator.tekton.dev/prune.resources"
- "operator.tekton.dev/prune.strategy"
- "operator.tekton.dev/prune.keep"
- "operator.tekton.dev/prune.keep-since"
- "operator.tekton.dev/prune.schedule"

Signed-off-by: Pradeep Kumar [email protected]

Changes

Submitter Checklist

These are the criteria that every PR should meet, please check them off as you
review them:

See the contribution guide for more details.

Release Notes

1) Introduce resource deletion as per the age.

keep-since newly introduced to tektonconfig, this is used to delete resources on the basis of their age.

     user wants to keep resources that are younger than 5 days.
     keep-since: 7200

Note: keep and keep-since are mutually exclusive. ie only one should be configured.

2) Introduce pruning config for each namespace.

With this pr user would be able to configure pruning uniquely for each namespace.
This can be achieved by annotation on the namespace.
The annotations introduced are as follows

  • "operator.tekton.dev/prune.skip"
    • if set as true, this particular namespace will be skipped for pruning
  • "operator.tekton.dev/prune.resources"
    • it can take the comma-separated value "taskrun, pipelinerun" if user wants to prune both resources, or a single resource "pipelinerun". This is similar to what we have in tektonconfig, only diff is it is a comma-separated string at the annotation level.
  • "operator.tekton.dev/prune.strategy"
    • strategy can have two values, "keep" or "keep-since"
    • The value for the strategy should be specified with below two annotations.
  • "operator.tekton.dev/prune.keep"
    • value for keep
  • "operator.tekton.dev/prune.keep-since"
    • value for keep-since
  • "operator.tekton.dev/prune.schedule"
    • If the value of the schedule is different than the value specified at the tektonconfig a new cron job in that particular namespace is created.

@tekton-robot tekton-robot added release-note Denotes a PR that will be considered when it comes time to generate release notes. do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. labels Sep 16, 2021
@tekton-robot tekton-robot added the size/XL Denotes a PR that changes 500-999 lines, ignoring generated files. label Sep 16, 2021
@tekton-robot
Copy link
Contributor

The following is the coverage report on the affected files.
Say /test pull-tekton-operator-go-coverage to re-run this coverage report

File Old Coverage New Coverage Delta
pkg/apis/operator/v1alpha1/tektonconfig_validation.go 89.7% 83.9% -5.8
pkg/reconciler/common/prune.go 52.9% 77.8% 24.8

@tekton-robot
Copy link
Contributor

The following is the coverage report on the affected files.
Say /test pull-tekton-operator-go-coverage to re-run this coverage report

File Old Coverage New Coverage Delta
pkg/apis/operator/v1alpha1/tektonconfig_validation.go 89.7% 90.3% 0.7
pkg/reconciler/common/prune.go 52.9% 77.8% 24.8

@pradeepitm12 pradeepitm12 changed the title WIP: adds auto-prune per namespace adds auto-prune per namespace Sep 20, 2021
@tekton-robot tekton-robot removed the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Sep 20, 2021
var containers []corev1.Container

cmdArgs := pruneCommand(nsConfig, ns)
jobName := SimpleNameGenerator.RestrictLengthWithRandomSuffix("pruner-tkn-" + ns)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

let us avoid the namespace suffix. it is redundant data and it doesn't help us with any functional benefits.

Im assuming that this was done to check a cronjob was created by this pruner logic. For that, let us add a label on the CornJob (example tektonconfig.operator.tekton.dev/pruner: true)

This will be more readable. It will also help us filter our query for cronJobs from allnamespaces.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In addition, we will create only 1 pruner CronJob in any given namespace.

ownerAPIVer = "operator.tekton.dev/v1alpha1"
ownerKind = "TektonConfig"
tektonSA = "tekton-pipelines-controller"
CronName = "resource-pruner"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

let us make this tektoncd-resorce-pruner

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This could be done. I am only thinking of updates, is there any chance the cronjob name change will create any problem with the updates?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we put annotation on the cronjob we create ? If yes, then we could/should probably not rely on the name, and thus changing it now wouldn't be a problem.
That said, where is this name use : inside openshift-pipelines (then it's fine to not have tektoncd prefix I would guess), or in any annotated namespace (then, yes, we should prefix it because we are not pruning all resources, just tektoncd ones).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

earlier label/annotation was not there.
We will be adding a label this time. #410 (comment)

@@ -98,11 +222,11 @@ func createCronJob(k kubernetes.Interface, ctx context.Context, pru v1alpha1.Pru
APIVersion: "batch/v1beta1",
},
ObjectMeta: v1.ObjectMeta{
Name: CronName,
Name: CronName + "-" + targetNs,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member

@vdemeester vdemeester left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • Is keep: 2 a default we will/would ship ? because if yes, it might be a tidy bit too small.
  • keep vs keepSince : I tend to agree that initially both "should" not be used together, but it could make sense though : I want to keep 100 pipelineruns and those since 4 weeks, and clean those who do not fit – If I have less than 100 in 4 weeks, I clean those after 4 weeks, if I have more than 100 in 4 weeks, I clean the 100 ; or the opposite, we would have to decide there.

ownerAPIVer = "operator.tekton.dev/v1alpha1"
ownerKind = "TektonConfig"
tektonSA = "tekton-pipelines-controller"
CronName = "resource-pruner"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we put annotation on the cronjob we create ? If yes, then we could/should probably not rely on the name, and thus changing it now wouldn't be a problem.
That said, where is this name use : inside openshift-pipelines (then it's fine to not have tektoncd prefix I would guess), or in any annotated namespace (then, yes, we should prefix it because we are not pruning all resources, just tektoncd ones).

Copy link
Member

@vdemeester vdemeester left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should remove the operator.tekton.dev/prune.resources.pipelineNames and operator.tekton.dev/prune.resources.taskNames from this feature / PR for now.

  • The feature is not present in the cluster-wide CR
  • It doesn't scale well, and we could probably give the user a better experience. On top of my head, we go with an annotation or a label, that if present on a TaskRun/PipelineRun, we would skip it — something like operator.tekton.dev/prune.ignore or something similar, and because we propagate annotation from pipeline to pipelinerun or task to taskrun, a Task or Pipeline could have this annotation too, to make all execution of it not be pruned.

pkg/reconciler/common/prune.go Outdated Show resolved Hide resolved
@vdemeester
Copy link
Member

/hold

@tekton-robot tekton-robot added do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. labels Sep 21, 2021
@tekton-robot tekton-robot removed the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Sep 30, 2021
@tekton-robot
Copy link
Contributor

The following is the coverage report on the affected files.
Say /test pull-tekton-operator-go-coverage to re-run this coverage report

File Old Coverage New Coverage Delta
pkg/apis/operator/v1alpha1/tektonconfig_validation.go 90.0% 88.2% -1.8
pkg/reconciler/common/prune.go 52.9% 72.3% 19.4

@@ -118,7 +118,7 @@ func (r *Reconciler) ReconcileKind(ctx context.Context, tc *v1alpha1.TektonConfi
}
}

if err := common.Prune(r.kubeClientSet, ctx, tc); err != nil {
if err := common.Prune(ctx, r.kubeClientSet, tc); err != nil {
logger.Error(err)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we have to report this error in TektonConfig Status.
eg:

tc.Status.MarkComponentNotReady(fmt.Sprintf("TektonTrigger: %s", err.Error()))

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

as it is not a resource like Triggers or Pipeline of operator, should we put tekton-resource-pruner
tc.Status.MarkComponentNotReady(fmt.Sprintf("tekton-resource-pruner: %s", err.Error()))

@tekton-robot
Copy link
Contributor

The following is the coverage report on the affected files.
Say /test pull-tekton-operator-go-coverage to re-run this coverage report

File Old Coverage New Coverage Delta
pkg/apis/operator/v1alpha1/tektonconfig_validation.go 90.0% 88.2% -1.8
pkg/reconciler/common/prune.go 52.9% 74.3% 21.4

@nikhil-thomas
Copy link
Member

/lgtm

@tekton-robot tekton-robot added the lgtm Indicates that a PR is ready to be merged. label Oct 7, 2021
This adds auto-pruning of taskrun and pipeline run per namespace
configured specifically.
adding unique schedule create a new cronjob in the annotated
namespace.
The default behaviour will persist, on top of it now user can
annotate a namespace with unique pruning configuration.
If user configures a unique schedule value by annotating a ns
a new cron job in that namespace will be created.

Auto purning is now enabled by default for default configurations
from tektonconfig.

Annotations introduced with this pr
- "operator.tekton.dev/prune.skip"
- "operator.tekton.dev/prune.resources"
- "operator.tekton.dev/prune.strategy"
- "operator.tekton.dev/prune.keep"
- "operator.tekton.dev/prune.keep-since"
- "operator.tekton.dev/prune.schedule"

Signed-off-by: Pradeep Kumar <[email protected]>
@vdemeester
Copy link
Member

/hold cancel
@pradeepitm12 needs a rebase

1 similar comment
@vdemeester
Copy link
Member

/hold cancel
@pradeepitm12 needs a rebase

@tekton-robot tekton-robot removed the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Oct 7, 2021
@tekton-robot tekton-robot removed the lgtm Indicates that a PR is ready to be merged. label Oct 7, 2021
@pradeepitm12
Copy link
Contributor Author

/hold cancel @pradeepitm12 needs a rebase

rebase Done

@tekton-robot
Copy link
Contributor

The following is the coverage report on the affected files.
Say /test pull-tekton-operator-go-coverage to re-run this coverage report

File Old Coverage New Coverage Delta
pkg/apis/operator/v1alpha1/tektonconfig_validation.go 90.0% 88.2% -1.8
pkg/reconciler/common/prune.go 52.9% 74.3% 21.4

@pradeepitm12
Copy link
Contributor Author

@nikhil-thomas @vdemeester
rebase Done.

@nikhil-thomas
Copy link
Member

/lgtm

@tekton-robot tekton-robot added the lgtm Indicates that a PR is ready to be merged. label Oct 8, 2021
@tekton-robot tekton-robot merged commit 0458922 into tektoncd:main Oct 8, 2021
adambkaplan added a commit to adambkaplan/shipwright-operator that referenced this pull request Dec 11, 2024
Starting in Tekton Operator v0.58.0, TektonConfig objects must set a
value for `keep` or `keepSince` if the pruner is enabled [1].
If Shipwright bootstraps the TektonConfig object and does not set a
value for `.spec.pruner.keep` (or `.keepSince`), it risks failing to
reconcile the TektonConfig instance or worse [2].

Fixing by setting the `keep` value to match the Tekton operator
default.

Fixes shipwright-io#231

[1] tektoncd/operator#410
[2] tektoncd/operator#2450
adambkaplan added a commit to adambkaplan/shipwright-operator that referenced this pull request Dec 11, 2024
Starting in Tekton Operator v0.58.0, TektonConfig objects must set a
value for `keep` or `keepSince` if the pruner is enabled [1].
If Shipwright bootstraps the TektonConfig object and does not set a
value for `.spec.pruner.keep` (or `.keepSince`), it risks failing to
reconcile the TektonConfig instance or worse [2].

Fixing by setting the `keep` value to match the Tekton operator
default.

Fixes shipwright-io#231

[1] tektoncd/operator#410
[2] tektoncd/operator#2450

Signed-off-by: Adam Kaplan <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. lgtm Indicates that a PR is ready to be merged. release-note Denotes a PR that will be considered when it comes time to generate release notes. size/XL Denotes a PR that changes 500-999 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants