Skip to content

KEP 1645: updates ServiceExport conditions #5437

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.

Sign up for GitHub

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

Merged
merged 1 commit into from
Jun 26, 2025
Merged

KEP 1645: updates ServiceExport conditions #5437

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
59 changes: 21 additions & 38 deletions keps/sig-multicluster/1645-multi-cluster-services-api/README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -435,43 +435,23 @@ type ServiceExportStatus struct {
// +patchMergeKey=type
// +listType=map
// +listMapKey=type
Conditions []ServiceExportCondition `json:"conditions,omitempty"`
Conditions []metav1.Condition `json:"conditions,omitempty" patchStrategy:"merge" patchMergeKey:"type"`
}

// ServiceExportConditionType identifies a specific condition.
type ServiceExportConditionType string

const {
// ServiceExportValid means that the service referenced by this
// service export has been recognized as valid by an mcs-controller.
// This will be false if the service is found to be unexportable
// (ExternalName, not found).
ServiceExportValid ServiceExportConditionType = "Valid"
// ServiceExportConflict means that there is a conflict between two
// exports for the same Service. When "True", the condition message
// should contain enough information to diagnose the conflict:
// field(s) under contention, which cluster won, and why.
// Users should not expect detailed per-cluster information in the
// conflict message.
ServiceExportConflict ServiceExportConditionType = "Conflict"
}

// ServiceExportCondition contains details for the current condition of this
// service export.
//
// Once KEP-1623 (sig-api-machinery/1623-standardize-conditions) is
// implemented, this will be replaced by metav1.Condition.
type ServiceExportCondition struct {
Type ServiceExportConditionType `json:"type"`
// Status is one of {"True", "False", "Unknown"}
Status corev1.ConditionStatus `json:"status"`
// +optional
LastTransitionTime *metav1.Time `json:"lastTransitionTime,omitempty"`
// +optional
Reason *string `json:"reason,omitempty"`
// +optional
Message *string `json:"message,omitempty"`
}
const (
// ServiceExportValid means that the service referenced by this
// service export has been recognized as valid by an mcs-controller.
// This will be false if the service is found to be unexportable
// (ExternalName, not found).
ServiceExportValid = "Valid"
// ServiceExportConflict means that there is a conflict between two
// exports for the same Service. When "True", the condition message
// should contain enough information to diagnose the conflict:
// field(s) under contention, which cluster won, and why.
// Users should not expect detailed per-cluster information in the
// conflict message.
ServiceExportConflict = "Conflict"
)
Copy link
Contributor

Choose a reason for hiding this comment

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

Perhaps we should just link to the Go code in the mcs-api repo rather than copying here and having to keep it up to date?

Copy link
Member Author

Choose a reason for hiding this comment

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

Hmm I don't think that works very well because when we are doing the opposite meaning modifying the KEP to then update the code there it is significantly more clear what you want to actually achieve to update this inline I think

Copy link
Contributor

@tpantelis tpantelis Jun 26, 2025 •
edited
Loading

Choose a reason for hiding this comment

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

Apparently we haven't been doing that workflow ☹️ Or perhaps we shouldn't expose Go code in the KEP and leave that implementation detail to the mcs-api repo. Eg, to me, it doesn't seem important in this document what Go struct is used to define the conditions or what Go constant name is used to define a condition type. Perhaps we provide examples solely in YAML format as is done on L458 below. I guess I see this doc as mainly outlining/defining concepts but perhaps I'm wrong there...

Copy link
Member Author

@MrFreezeex MrFreezeex Jun 26, 2025 •
edited
Loading

Choose a reason for hiding this comment

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

AFAIK for new fields and things like that we have been doing this workflow mostly, and it should probably have been done for this condition change a while ago too.

I don't think that it's super important that this go code inline match absolutely 1:1 what we have in the mcs-api repo, it's not a big deal if small details drift. This one isn't that small though and the most important part is that I personally got super confused and had to debug this for longer than necessary when I did the Cilium implementation because I had to discover that the message field was required now so at the very least the yaml update below solves that...

Copy link
Contributor

Choose a reason for hiding this comment

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

OK.

BTW: while the message field is required in the CRD def, it can be empty. I was wondering about that too initially. When using the Go structs, Message is a non-pointer so is rendered as message: "" if not specified in code. However reason cannot be empty as it has a regex pattern which disallows empty.

Copy link
Member Author

@MrFreezeex MrFreezeex Jun 26, 2025 •
edited
Loading

Choose a reason for hiding this comment

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

Argh indeed I forgot about Reason vs Message I definitely want to update that to not bamboozle future implementers :/

Copy link
Member Author

Choose a reason for hiding this comment

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

here is the PR fixing that: #5437

Copy link
Member Author

Choose a reason for hiding this comment

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

If I am copy pasting this correctly it would work better :/: #5438

```
```yaml
apiVersion: multicluster.k8s.io/v1alpha1
Expand All @@ -483,9 +463,11 @@ status:
conditions:
- type: Ready
status: "True"
message: "Service export is ready"
lastTransitionTime: "2020-03-30T01:33:51Z"
- type: InvalidService
status: "False"
- type: Valid
status: "True"
message: "Service export is valid"
lastTransitionTime: "2020-03-30T01:33:55Z"
- type: Conflict
status: "True"
Expand Down Expand Up @@ -704,7 +686,8 @@ this cluster.
complicate deployments by even attempting to stretch them across clusters.
Instead, regular `ExternalName` type `Services` should be created in each
cluster individually. If a `ServiceExport` is created for an `ExternalName`
service, an `InvalidService` condition will be set on the export.
service, a condition type `Valid` with a `false` status will be set on the
`ServiceExport`.

#### ClusterSetIP

Expand Down