SHIP-0034: Label propagation #86
Conversation
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
/assign @SaschaSchwarze0 (I'm not sure I should assign it now, as I understand it, the EP approval is a process that happens before it's complete and ready) |
SaschaSchwarze0
changed the title
SaschaSchwarze0
changed the title
There was a problem hiding this comment.
Hi @Pinolo, thank you for your contribution. That's very valuable. I must say sorry. We were quite busy with v0.10 and cdCon preparation recently.
Please rename your file, I renamed your PR already. You now have SHIP 0034.
Please mention that doumentation will be needed.
|
|
||
| The implementation requires the [BuilderStrategy interface](../../pkg/apis/build/v1alpha1/buildstrategy.go) to be extended with a `GetLabels` functions that is implemented in the [BuildStrategy](../../pkg/apis/build/v1alpha1/buildstrategy_types.go) and [ClusterBuildStrategy](../../pkg/apis/build/v1alpha1/clusterbuildstrategy_types.go) types by returning the object's labels. | ||
|
|
||
| It also requires `GetLabels` functions to be implemented in the [Build](../../pkg/apis/build/v1alpha1/build_types.go) and [BuildRun](../../pkg/apis/build/v1alpha1/buildrun_types.go) types. |
There was a problem hiding this comment.
This is not needed because the Build and BuildRun type are Kubernetes objects which have those functions available by default.
|
|
||
| ### Implementation Notes | ||
|
|
||
| The implementation requires the [BuilderStrategy interface](../../pkg/apis/build/v1alpha1/buildstrategy.go) to be extended with a `GetLabels` functions that is implemented in the [BuildStrategy](../../pkg/apis/build/v1alpha1/buildstrategy_types.go) and [ClusterBuildStrategy](../../pkg/apis/build/v1alpha1/clusterbuildstrategy_types.go) types by returning the object's labels. |
There was a problem hiding this comment.
You only need to define the function on the interface. The implementation is already available on the Kubernetes generated types.
| The assignment of the `TaskRun` labels needs to be done in the [generate_taskrun.go](../../pkg/reconciler/buildrun/resources/taskrun.go) file in the `GenerateTaskRun` function. The labels from the build strategy need to be copied to the `TaskRun` except those with reserved prefixes mentioned under [Proposal](#proposal). | ||
|
|
||
| Making sure the assignment takes place in the desired order (first labels from `BuilderStrategy`, then from `Build`, and finally from `BuildRun`) will allow cascading overrides. |
There was a problem hiding this comment.
You should merge these two paragraphs to make it more obvious. Currently the first paragraph mentions that labels only from the build strategy need to be copied. Your second paragraph discussed the override behavior.
| Shipwright resources administrators can define labels in the metadata, as with all Kubernetes objects, see the [Labels](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/) topic in the Kubernetes documentation. | ||
|
|
||
| As we did with annotations, we reserve certain label prefixes that are either used by Kubernetes or Tekton or Shipwright's controller: | ||
|
|
||
| * `?kubernetes.io` | ||
| * `?k8s.io` | ||
| * `tekton.dev` | ||
| * `*.shipwright.io` |
There was a problem hiding this comment.
I think you should here discuss the differences between labels and annotations. Conceptionally. You already link to the Kubernetes documentation about labels. There's a topic about annotations as well. The difference is clearly stated. While labels are described as Labels enable users to map their own organizational structures onto system objects in a loosely coupled fashion, without requiring clients to store these mappings., annotations (https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/) have a broader scope inclusing Directives from the end-user to the implementations to modify behavior or engage non-standard features.
Based on Kubernetes' definition, one can easily conclude that labels are safe to be propagated because they cannot be used to possibly enable unwanted behavior.
The caveat/risk you can mention is that implementations are out there which want to modify behavior, but also require the filtering capabilities of labels - and therefore use labels for behavior. Istio is an example, https://istio.io/latest/docs/setup/additional-setup/sidecar-injection/#controlling-the-injection-policy.
And that's where it becomes interesting. I personally still think that we can do propagation also from Build and BuildRun.
Our general strategy on that is that we delegate such things to policy management solutions (though we don't have a SHIP for this, like Tekton has, https://github.com/tektoncd/community/blob/main/teps/0035-document-tekton-position-around-policy-authentication-authorization.md).
There was a problem hiding this comment.
Thanks for the insightful digression. I see your point in adding a little background about different purpose for labels and annotations, and I will update the document accordingly.
Regarding the caveat/risk discussion, I see that I actually jumped to a conclusion (to protect shipwright's own dependencies labels) which is quite arbitrary. Considering the main purpose of labels (filtering), I believe use cases may arise where users want to add/override tekton or even k8s key prefixes. Also, the Istio situation is quite tricky, but maybe we don't want to handle it, and delegate it to policy management, as you suggest, possibly in a documented way.
As for shipwright's own labels, I don't know…
Could a solomonic resolution be to allow adding prefixes to "protected" patterns, while disallowing overrides?
|
|
||
| ### Test Plan | ||
|
|
||
| TBD |
There was a problem hiding this comment.
I think unit and integration tests are necessary.
No description provided.