Prow job labeled with prow version #21054
Conversation
As proposed in kubernetes/enhancements#2540, k8s prow will be bumped more frequently than once per work day, adding this label to the job so that it could help associate failures with specific prow versions
k8s-ci-robot
added
the
cncf-cla: yes
|
/cc @spiffxp |
k8s-ci-robot
added
approved
|
/retest |
k8s-ci-robot
added
the
do-not-merge/hold
k8s-ci-robot
added
the
lgtm
prow/kube/prowjob.go
Outdated
| @@ -41,6 +41,9 @@ const ( | |||
| // job names can be arbitrarily long, this is added as | |||
| // an annotation instead of a label. | |||
| ProwJobAnnotation = "prow.k8s.io/job" | |||
| // ProwVersionLabel is added in resources created by prow and | |||
| // carries the version of prow that decorated this job. | |||
| ProwVersionLabel = "prow.k8s.io/version" | |||
There was a problem hiding this comment.
We deploy all prow components as a bunch of micro services in lockstep today. It may be worth considering the versions of the components themselves though.
In terms of components that would be relevant to why pods landed on a cluster and how they ended up in their current form. Ideally we could have:
- prow.k8s.io/hook-version is responsible for triggering a job in response to GitHub events
- prow.k8s.io/plank-version is responsible for making a pod out of a prowjob
- prow is using a specific config when creating this pod (sha of the repo from which the config was deployed? hash of configmap contents? revision of the configmap resource?), or maybe specific component and job configs
There was a problem hiding this comment.
A better approach to this would be leverage the managedFields. We would need to figure out how to set a correct fieldmanager (xref kubernetes-sigs/controller-runtime#1215), then something like kubect-blame can be used to figure out what component in what version set which fields. Requires kube 1.18 though.
There was a problem hiding this comment.
Although hm, they are intended as user identifier in server side apply, which means if we put a version inside that, we would prevent ourselves from starting to use server side apply, if we ever wanted.
There was a problem hiding this comment.
The nice thing about labels in my experience is they automatically get attached to metrics within google cloud monitoring, and I'm pretty sure kubernetes/kube-state-metrics does the same.
The more I think about it,prow.k8s.io/plank-version makes sense to start with, as that is the thing creating the pod. Some time later I could see prow.k8s.io/hook-version getting attached to ProwJobs created by hook, and propagating through (since it's entirely possible for ProwJobs to be created by something other than hook)
There was a problem hiding this comment.
Good point and done
k8s-ci-robot
removed
the
lgtm
|
/unhold |
k8s-ci-robot
removed
the
do-not-merge/hold
k8s-ci-robot
added
the
lgtm
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: chaodaiG, fejta, spiffxp 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 |
As proposed in kubernetes/enhancements#2540, k8s prow will be bumped more frequently than once per work day, adding this label to the job so that it could help associate failures with specific prow versions