KEP 1645: add labels and annotations export #4922

MrFreezeex · 2024-10-16T13:14:55Z

One-line PR description: add labels and annotations export

Issue link: Multi-Cluster Services API #1645

Other comments: Add new fields in the ServiceExport resources to sync labels and annotations. This approach is inspired by the GatewayAPI (https://gateway-api.sigs.k8s.io/geps/gep-1762/#labels-and-annotations) one to have dedicated fields for that and there's some explanation inline in the KEP why we might favor that.

k8s-ci-robot · 2024-10-16T13:14:57Z

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

keps/sig-multicluster/1645-multi-cluster-services-api/README.md

Signed-off-by: Arthur Outhenin-Chalandre <arthur@cri.epita.fr>

skitt · 2024-11-28T15:53:15Z

/approve

@mikemorris, @JeremyOT, @lauralorenz could you take a look (after Thanksgiving week-end I imagine 😉)?

mikemorris · 2024-12-10T03:03:03Z

Will prioritize reviewing this and kubernetes-sigs/mcs-api/pull/85 this week.

mikemorris

/approve

This feels good to me - it's both simpler and more flexible than the "copy/filter" strategy to start, and with the tweak I suggested from "annotations or labels must not be exported from the metadata" to "values specified in spec.exportedLabels or spec.exportedAnnotations MUST take precedence" I think we have future design space if we determine the alternative UX is needed in the future.

mikemorris · 2024-12-11T04:50:20Z

keps/sig-multicluster/1645-multi-cluster-services-api/README.md

+supported by MCS-API implementations. If supported, annotations or labels must
+not be exported from the `metadata` of the `Service` or `ServiceExport` resources.


Suggested change

supported by MCS-API implementations. If supported, annotations or labels must

not be exported from the `metadata` of the `Service` or `ServiceExport` resources.

supported by MCS-API implementations. If supported, values specified in

`spec.exportedLabels` or `spec.exportedAnnotations` MUST take precedence over any

labels or annotations which may be synced or copied from the `metadata` of the

`Service` or `ServiceExport` resources.

I think this tweak would give us design space to implement a "copy filter" strategy either globally in implementation configuration or locally via additional fields on ServiceExport if we find a need to add that in the future but without adding additional complexity now.

I am not sure I agree with this because it is intentionally vague about what implementation should do (does precedence means merging or completely overriding?), if we find the need to change that behavior I would just edit those sentence rather than having something somewhat unclear to begin with

mikemorris · 2024-12-11T05:00:42Z

keps/sig-multicluster/1645-multi-cluster-services-api/README.md

@@ -1013,6 +1029,13 @@ Session affinity affects a service as a whole for a given consumer. The derived
 service's session affinity will be decided according to the conflict resolution
 policy.

+#### Labels and Annotations
+
+If supported, exporting labels and annotations would affect a `Service` as a whole


Suggested change

If supported, exporting labels and annotations would affect a `Service` as a whole

If supported, exporting labels and annotations would affect a service as a whole

For consistency with the above sections which do not explicitly mention the Service resource - my reading is that a derived Service resource is an optional implementation detail which is one component of the "service as a whole".

I see this would revert @sftim's prior suggested change in #4922 (comment)

mikemorris · 2024-12-11T05:04:46Z

keps/sig-multicluster/1645-multi-cluster-services-api/README.md

@@ -1229,7 +1252,7 @@ retain the flexibility of selectors.

 ### Export via annotation

-`ServiceExport` as described has no spec and seems like it could just be
+`ServiceExport` initially had no spec and seemed like it could just be


Out of scope for this change, but I think the original rationale here is actually outdated - the Service resource does have a status.conditions field now https://kubernetes.io/docs/reference/kubernetes-api/service-resources/service-v1/#ServiceStatus

This is about ServiceExport spec so I would say it should still be right?

This section is describing why a ServiceExport resource with no spec was originally proposed at all - the ServiceExport status was intended to fill a UX gap from Service lacking a status.conditions field to message if an annotation-based API on Service to indicate an intent to export would have been successful or conflicted. It's not directly applicable to the focus of this PR though, I may update the language for historical purposes in a separate PR.

mikemorris · 2024-12-11T05:09:49Z

keps/sig-multicluster/1645-multi-cluster-services-api/README.md

+`ServiceExport` or `Service` resources, it may be more confusing for users as it
+would be the only fields present in both resources. For instance, should an


Suggested change

`ServiceExport` or `Service` resources, it may be more confusing for users as it

would be the only fields present in both resources. For instance, should an

`ServiceExport` or `Service` resources, it may be more confusing for users.

For instance, should an

I didn't quite understand this, and think the point is clear without this phrase.

mikemorris · 2024-12-11T05:13:14Z

keps/sig-multicluster/1645-multi-cluster-services-api/README.md

+and annotations in the spec of the `ServiceExport` resource, it may becomes more
+straightforward that each resource have their own labels and annotations in their
+metadata and that the exported labels and annotations are from the dedicated
+fields in the `ServiceExport` spec.


Suggested change

and annotations in the spec of the `ServiceExport` resource, it may becomes more

straightforward that each resource have their own labels and annotations in their

metadata and that the exported labels and annotations are from the dedicated

fields in the `ServiceExport` spec.

and annotations in the spec of the `ServiceExport` resource, we expect it will be

straightforward that while each resource has their own labels and annotations in their

metadata, the exported labels and annotations are from the dedicated fields in the

`ServiceExport` spec.

Minor phrasing nit.

mikemorris · 2024-12-11T05:31:24Z

keps/sig-multicluster/1645-multi-cluster-services-api/README.md

+from the `Service` and `ServiceExport` metadata. More flexibility could also be
+achieved with CEL expression on the `ServiceExport` at the cost of greater


Suggested change

from the `Service` and `ServiceExport` metadata. More flexibility could also be

achieved with CEL expression on the `ServiceExport` at the cost of greater

from the `Service` and `ServiceExport` metadata.

This implementation does not preclude the possibility of additionally adopting a

"copy/filter" strategy (either as global configuration for a particular implementation, or

granularly as additional `ServiceExport` fields) if the need arises. Such an strategy could

select specific label or annotation keys to sync from the `Service` by exact name, by

prefix, or further flexibility could be achieved with CEL expressions at the cost of

greater

Feel free to reject this suggestion - from the long thread above this felt like this possibility could be worth mentioning but perhaps the "exportedLabels and exportedAnnotations MUST take precedence" snippet I suggested adding above is a sufficent oblique reference without introducing confusion.

A bit similar to the previous thread I would recommend to keep the kep consistent for all implementations regarding this for now and if the need arises we should just update it IMO or make it more loose

JeremyOT · 2024-12-11T05:41:35Z

This looks good to me, thank you!

/lgtm
/approve

k8s-ci-robot · 2024-12-11T05:41:44Z

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: JeremyOT, mikemorris, MrFreezeex, skitt

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:

~~keps/sig-multicluster/OWNERS~~ [JeremyOT,skitt]

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

ryanzhang-oss · 2024-10-29T16:42:28Z

keps/sig-multicluster/1645-multi-cluster-services-api/README.md

+// ServiceExportSpec describes an exported service and extra exported information
+type ServiceExportSpec struct {
+        // +optional
+        ExportedLabels map[string]string `json:"exportedLabels"`


Suggested change

ExportedLabels map[string]string `json:"exportedLabels"`

ExportedLabels map[string]string `json:"exportedLabels,omitempty"`

Ah yep nice catch! It's already like that in the associated PR for the CRD but the KEP should be amended indeed

k8s-ci-robot added do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. labels Oct 16, 2024

k8s-ci-robot requested review from JeremyOT and skitt October 16, 2024 13:15

k8s-ci-robot added kind/kep Categorizes KEP tracking issues and PRs modifying the KEP directory sig/multicluster Categorizes an issue or PR as relevant to SIG Multicluster. size/M Denotes a PR that changes 30-99 lines, ignoring generated files. labels Oct 16, 2024

MrFreezeex force-pushed the KEP1645-sync-labels-annotations branch 2 times, most recently from 939b732 to 2ae4c68 Compare October 16, 2024 13:16

MrFreezeex marked this pull request as ready for review October 16, 2024 13:20

k8s-ci-robot removed the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Oct 16, 2024

MrFreezeex force-pushed the KEP1645-sync-labels-annotations branch 2 times, most recently from 6b7282b to a849f28 Compare October 16, 2024 13:27

tpantelis reviewed Oct 16, 2024

View reviewed changes

MrFreezeex force-pushed the KEP1645-sync-labels-annotations branch from a849f28 to 4960c5b Compare October 16, 2024 14:46

skitt reviewed Oct 16, 2024

View reviewed changes

keps/sig-multicluster/1645-multi-cluster-services-api/README.md Outdated Show resolved Hide resolved

MrFreezeex force-pushed the KEP1645-sync-labels-annotations branch 5 times, most recently from b33c1eb to 83d1af6 Compare October 18, 2024 11:10

sftim reviewed Nov 11, 2024

View reviewed changes

keps/sig-multicluster/1645-multi-cluster-services-api/README.md Outdated Show resolved Hide resolved

keps/sig-multicluster/1645-multi-cluster-services-api/README.md Show resolved Hide resolved

keps/sig-multicluster/1645-multi-cluster-services-api/README.md Show resolved Hide resolved

KEP 1645: add labels and annotations export

271740f

Signed-off-by: Arthur Outhenin-Chalandre <arthur@cri.epita.fr>

MrFreezeex force-pushed the KEP1645-sync-labels-annotations branch from 83d1af6 to 271740f Compare November 12, 2024 09:59

k8s-ci-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Nov 28, 2024

This was referenced Dec 2, 2024

apis: conformance: add labels and annotation export kubernetes-sigs/mcs-api#84

Open

clustermesh: add annotations and labels sync to MCS-API cilium/cilium#36308

Draft

mikemorris approved these changes Dec 11, 2024

View reviewed changes

k8s-ci-robot assigned JeremyOT Dec 11, 2024

k8s-ci-robot added the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Dec 11, 2024

k8s-ci-robot merged commit 3fb4087 into kubernetes:master Dec 11, 2024
4 checks passed

k8s-ci-robot added this to the v1.32 milestone Dec 11, 2024

ryanzhang-oss reviewed Dec 11, 2024

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

KEP 1645: add labels and annotations export #4922

KEP 1645: add labels and annotations export #4922

MrFreezeex commented Oct 16, 2024 •

edited

Loading

k8s-ci-robot commented Oct 16, 2024

skitt commented Nov 28, 2024 •

edited

Loading

mikemorris commented Dec 10, 2024 •

edited

Loading

mikemorris left a comment •

edited

Loading

mikemorris Dec 11, 2024 •

edited

Loading

MrFreezeex Dec 11, 2024

mikemorris Dec 11, 2024

mikemorris Dec 11, 2024

mikemorris Dec 11, 2024

MrFreezeex Dec 11, 2024

mikemorris Dec 11, 2024 •

edited

Loading

mikemorris Dec 11, 2024

mikemorris Dec 11, 2024

mikemorris Dec 11, 2024

MrFreezeex Dec 11, 2024

JeremyOT commented Dec 11, 2024

k8s-ci-robot commented Dec 11, 2024

ryanzhang-oss Oct 29, 2024

MrFreezeex Dec 12, 2024

		supported by MCS-API implementations. If supported, annotations or labels must
		not be exported from the `metadata` of the `Service` or `ServiceExport` resources.

	If supported, exporting labels and annotations would affect a `Service` as a whole
	If supported, exporting labels and annotations would affect a service as a whole

		`ServiceExport` or `Service` resources, it may be more confusing for users as it
		would be the only fields present in both resources. For instance, should an

		from the `Service` and `ServiceExport` metadata. More flexibility could also be
		achieved with CEL expression on the `ServiceExport` at the cost of greater

-from the `Service` and `ServiceExport` metadata. More flexibility could also be
-achieved with CEL expression on the `ServiceExport` at the cost of greater
+from the `Service` and `ServiceExport` metadata.
+This implementation does not preclude the possibility of additionally adopting a
+"copy/filter" strategy (either as global configuration for a particular implementation, or
+granularly as additional `ServiceExport` fields) if the need arises. Such an strategy could
+select specific label or annotation keys to sync from the `Service` by exact name, by
+prefix, or further flexibility could be achieved with CEL expressions at the cost of
+greater

	ExportedLabels map[string]string `json:"exportedLabels"`
	ExportedLabels map[string]string `json:"exportedLabels,omitempty"`

KEP 1645: add labels and annotations export #4922

KEP 1645: add labels and annotations export #4922

Conversation

MrFreezeex commented Oct 16, 2024 • edited Loading

k8s-ci-robot commented Oct 16, 2024

skitt commented Nov 28, 2024 • edited Loading

mikemorris commented Dec 10, 2024 • edited Loading

mikemorris left a comment • edited Loading

Choose a reason for hiding this comment

mikemorris Dec 11, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mikemorris Dec 11, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

JeremyOT commented Dec 11, 2024

k8s-ci-robot commented Dec 11, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

MrFreezeex commented Oct 16, 2024 •

edited

Loading

skitt commented Nov 28, 2024 •

edited

Loading

mikemorris commented Dec 10, 2024 •

edited

Loading

mikemorris left a comment •

edited

Loading

mikemorris Dec 11, 2024 •

edited

Loading

mikemorris Dec 11, 2024 •

edited

Loading