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

Dereference the TaskSpec into TaskRun.Status. #2444

Merged
merged 1 commit into from
Apr 23, 2020

Conversation

dlorenc
Copy link
Contributor

@dlorenc dlorenc commented Apr 20, 2020

Changes

The Task definition used for a TaskRun can change after the TaskRun
has started. This poses problems for auditability post-run. Rather
than chase down every part of a Task that we might like to audit later,
let's just add the entire thing here.

This is a replacement for #2399

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.

Double check this list of stuff that's easy to miss:

Reviewer Notes

If API changes are included, additive changes must be approved by at least two OWNERS and backwards incompatible changes must be approved by more than 50% of the OWNERS, and they must first be added in a backwards compatible way.

Release Notes

The TaskRun.Status now contains a TaskSpec field, including the full dereferenced Task used to instantiate the run.

@googlebot googlebot added the cla: yes Trying to make the CLA bot happy with ppl from different companies work on one commit label Apr 20, 2020
@tekton-robot tekton-robot added the size/S Denotes a PR that changes 10-29 lines, ignoring generated files. label Apr 20, 2020
@afrittoli
Copy link
Member

Nice, I was going to work on this after I finished #2421 :)
This is both a benefit to auditability, but it also should improve the reconcile performance, since we now fetch the task on every reconcile cycle.
Once we start fetching tasks from an OCI registry, it will be even more relevant.

One though I have is that we should also store resources in the status.

@dlorenc
Copy link
Contributor Author

dlorenc commented Apr 20, 2020

/test pull-tekton-pipeline-integration-tests

Copy link
Member

@afrittoli afrittoli left a comment

Choose a reason for hiding this comment

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

Thanks for this!
I have one comment on this.
Even if only use it for audit for now, I would still add the task to the status when we first obtain the task

@@ -116,6 +118,12 @@ func MakeTaskRunStatus(logger *zap.SugaredLogger, tr v1alpha1.TaskRun, pod *core
trs.Steps = []v1alpha1.StepState{}
trs.Sidecars = []v1alpha1.SidecarState{}

ts := v1beta1.TaskSpec{}
Copy link
Member

Choose a reason for hiding this comment

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

We might want to store this into the TaskRun status when we first fetch it, i.e.

getTaskFunc, kind := c.getTaskFunc(tr)
taskMeta, taskSpec, err := resources.GetTaskData(ctx, tr, getTaskFunc)

We could then modify that could to fetch the task only if not available in the status, and else use that from status

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Whoa, yeah thanks. Do you think it's enough to only set this once, the first time?

Copy link
Member

Choose a reason for hiding this comment

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

Yes, I think that would be great! Especially when the task spec is not embedded in the taskrun spec, this avoids issues when the task definition is updated during the run.

The only case where is use the change to the spec for something is cancel, so we would have to find an alternative for that. Perhaps the tkn client could reset the task definition in status to force a reload? @vdemeester what do you think?

Copy link
Member

Choose a reason for hiding this comment

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

Oh, actually it would not break cancel since that goes in the spec of the taskrun, not of the task - so fetching the task only once would work just fine!

Copy link
Member

Choose a reason for hiding this comment

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

yeah

@tekton-robot tekton-robot added size/M Denotes a PR that changes 30-99 lines, ignoring generated files. and removed size/S Denotes a PR that changes 10-29 lines, ignoring generated files. labels Apr 20, 2020
@dlorenc
Copy link
Contributor Author

dlorenc commented Apr 20, 2020

One though I have is that we should also store resources in the status.

I hesitated on this one for now. We get some of the resource info in the status now (under containers):

{
      "container": "step-git-source-skaffold-git-build-push-kaniko-p28nk",
      "imageID": "docker-pullable://gcr.io/dlorenc-vmtest2/git-init-4874978a9786b6625dd8b6ef2a21aa70@sha256:99f410cc098b4300384ad056c8febf5bb79e4749417b5e9621fc529514c4a0c3",
      "name": "git-source-skaffold-git-build-push-kaniko-p28nk",
      "terminated": {
        "containerID": "docker://b96396af17dea856526547ef5e140478148d4d672c8bda8a95e6010380e7cfab",
        "exitCode": 0,
        "finishedAt": "2020-04-20T15:32:20Z",
        "message": "[{\"key\":\"commit\",\"value\":\"6ed7aad5e8a36052ee5f6079fc91368e362121f7\",\"resourceRef\":{\"name\":\"skaffold-git-build-push-kaniko\"}}]",
        "reason": "Completed",
        "startedAt": "2020-04-20T15:32:18Z"
      }
    },

This doesn't include commands/arguments, but it's close. We also get resourcesResults.

Should we add them to the v1beta1 API, given we don't know the future of them yet? #2447

Copy link
Member

@afrittoli afrittoli left a comment

Choose a reason for hiding this comment

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

/lgtm

pkg/pod/status.go Outdated Show resolved Hide resolved
@tekton-robot tekton-robot added the lgtm Indicates that a PR is ready to be merged. label Apr 21, 2020
@tekton-robot tekton-robot removed the lgtm Indicates that a PR is ready to be merged. label Apr 21, 2020
@linux-foundation-easycla
Copy link

linux-foundation-easycla bot commented Apr 21, 2020

CLA Check
The committers are authorized under a signed CLA.

@dlorenc dlorenc force-pushed the deref branch 2 times, most recently from 1f9c107 to 12304b5 Compare April 21, 2020 19:03
Copy link
Member

@afrittoli afrittoli left a comment

Choose a reason for hiding this comment

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

Thanks for this!
We should do the same for pipelines :)
/approve

pkg/reconciler/taskrun/taskrun.go Show resolved Hide resolved
@tekton-robot
Copy link
Collaborator

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: afrittoli

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@tekton-robot tekton-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Apr 21, 2020
@dlorenc dlorenc force-pushed the deref branch 2 times, most recently from 9ff346b to b6cedcb Compare April 22, 2020 15:48
@tekton-robot tekton-robot added size/XL Denotes a PR that changes 500-999 lines, ignoring generated files. and removed size/M Denotes a PR that changes 30-99 lines, ignoring generated files. labels Apr 22, 2020
@dlorenc dlorenc force-pushed the deref branch 2 times, most recently from fb4ddc3 to 5cff4f6 Compare April 22, 2020 15:56
@tekton-robot tekton-robot added size/M Denotes a PR that changes 30-99 lines, ignoring generated files. and removed size/XL Denotes a PR that changes 500-999 lines, ignoring generated files. labels Apr 22, 2020
```
kubectl get taskrun <name>
```
The exact Task Spec used to instantiate the TaskRun is also included in the Status for full auditability.
Copy link
Collaborator

Choose a reason for hiding this comment

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

🎉

@dlorenc
Copy link
Contributor Author

dlorenc commented Apr 23, 2020

/test pull-tekton-pipeline-build-tests

The Task definition used for a TaskRun can change after the TaskRun
has started. This poses problems for auditability post-run. Rather
than chase down every part of a Task that we might like to audit later,
let's just add the entire thing here.

This is a replacement for tektoncd#2399
@tekton-robot tekton-robot removed the lgtm Indicates that a PR is ready to be merged. label Apr 23, 2020
@dlorenc
Copy link
Contributor Author

dlorenc commented Apr 23, 2020

/test pull-tekton-pipeline-integration-tests

@dibyom
Copy link
Member

dibyom commented Apr 23, 2020

/lgtm

@tekton-robot tekton-robot added the lgtm Indicates that a PR is ready to be merged. label Apr 23, 2020
@dlorenc
Copy link
Contributor Author

dlorenc commented Apr 23, 2020

/test pull-tekton-pipeline-integration-tests

@skaegi
Copy link
Contributor

skaegi commented Apr 23, 2020

Yep. Apart from my own selfish utility concerns ;) size in etcd is the only real concern. This is still fairly safe and not going to break anything for us.

@dlorenc
Copy link
Contributor Author

dlorenc commented Apr 23, 2020

/test pull-tekton-pipeline-integration-tests

@dibyom
Copy link
Member

dibyom commented Apr 23, 2020

/test pull-tekton-pipeline-build-tests

@tekton-robot tekton-robot merged commit 0c2798e into tektoncd:master Apr 23, 2020
@dlorenc dlorenc deleted the deref branch April 24, 2020 13:26
dlorenc added a commit to dlorenc/build-pipeline that referenced this pull request Apr 24, 2020
The Pipeline definition used for a PipelineRun can change after the
PipelineRun has started. This poses problems for auditability post-run. Rather
than chase down every part of a Pipeline that we might like to audit later,
let's just add the entire thing here.

This is a follow up to tektoncd#2444.
dlorenc added a commit to dlorenc/build-pipeline that referenced this pull request Apr 24, 2020
The Pipeline definition used for a PipelineRun can change after the
PipelineRun has started. This poses problems for auditability post-run. Rather
than chase down every part of a Pipeline that we might like to audit later,
let's just add the entire thing here.

This is a follow up to tektoncd#2444.
dlorenc added a commit to dlorenc/build-pipeline that referenced this pull request Apr 27, 2020
The Pipeline definition used for a PipelineRun can change after the
PipelineRun has started. This poses problems for auditability post-run. Rather
than chase down every part of a Pipeline that we might like to audit later,
let's just add the entire thing here.

This is a follow up to tektoncd#2444.
tekton-robot pushed a commit that referenced this pull request Apr 27, 2020
The Pipeline definition used for a PipelineRun can change after the
PipelineRun has started. This poses problems for auditability post-run. Rather
than chase down every part of a Pipeline that we might like to audit later,
let's just add the entire thing here.

This is a follow up to #2444.
@afrittoli afrittoli added the kind/feature Categorizes issue or PR as related to a new feature. label Apr 30, 2020
@bobcatfish
Copy link
Collaborator

I believe this and #2489 fixed #279

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. cla: yes Trying to make the CLA bot happy with ppl from different companies work on one commit kind/feature Categorizes issue or PR as related to a new feature. lgtm Indicates that a PR is ready to be merged. size/M Denotes a PR that changes 30-99 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants