Skip to content

Commit 9620ade

Browse files
committed
KEP 1645: updates ServiceExport conditions
ServiceExport conditions in the KEP are not reflecting what's actually done in the CRD as this predates the addition of the Condition type in Kubernetes. This commit essentially put back all the condition types that we actually have in MCS-API code and change the reference in the example (the regular kubernetes type requires a message to be added!) Signed-off-by: Arthur Outhenin-Chalandre <[email protected]>
1 parent d551d45 commit 9620ade

File tree

1 file changed

+21
-38
lines changed
  • keps/sig-multicluster/1645-multi-cluster-services-api

1 file changed

+21
-38
lines changed

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

Lines changed: 21 additions & 38 deletions
Original file line numberDiff line numberDiff line change
@@ -435,43 +435,23 @@ type ServiceExportStatus struct {
435435
// +patchMergeKey=type
436436
// +listType=map
437437
// +listMapKey=type
438-
Conditions []ServiceExportCondition `json:"conditions,omitempty"`
438+
Conditions []metav1.Condition `json:"conditions,omitempty" patchStrategy:"merge" patchMergeKey:"type"`
439439
}
440440

441-
// ServiceExportConditionType identifies a specific condition.
442-
type ServiceExportConditionType string
443-
444-
const {
445-
// ServiceExportValid means that the service referenced by this
446-
// service export has been recognized as valid by an mcs-controller.
447-
// This will be false if the service is found to be unexportable
448-
// (ExternalName, not found).
449-
ServiceExportValid ServiceExportConditionType = "Valid"
450-
// ServiceExportConflict means that there is a conflict between two
451-
// exports for the same Service. When "True", the condition message
452-
// should contain enough information to diagnose the conflict:
453-
// field(s) under contention, which cluster won, and why.
454-
// Users should not expect detailed per-cluster information in the
455-
// conflict message.
456-
ServiceExportConflict ServiceExportConditionType = "Conflict"
457-
}
458-
459-
// ServiceExportCondition contains details for the current condition of this
460-
// service export.
461-
//
462-
// Once KEP-1623 (sig-api-machinery/1623-standardize-conditions) is
463-
// implemented, this will be replaced by metav1.Condition.
464-
type ServiceExportCondition struct {
465-
Type ServiceExportConditionType `json:"type"`
466-
// Status is one of {"True", "False", "Unknown"}
467-
Status corev1.ConditionStatus `json:"status"`
468-
// +optional
469-
LastTransitionTime *metav1.Time `json:"lastTransitionTime,omitempty"`
470-
// +optional
471-
Reason *string `json:"reason,omitempty"`
472-
// +optional
473-
Message *string `json:"message,omitempty"`
474-
}
441+
const (
442+
// ServiceExportValid means that the service referenced by this
443+
// service export has been recognized as valid by an mcs-controller.
444+
// This will be false if the service is found to be unexportable
445+
// (ExternalName, not found).
446+
ServiceExportValid = "Valid"
447+
// ServiceExportConflict means that there is a conflict between two
448+
// exports for the same Service. When "True", the condition message
449+
// should contain enough information to diagnose the conflict:
450+
// field(s) under contention, which cluster won, and why.
451+
// Users should not expect detailed per-cluster information in the
452+
// conflict message.
453+
ServiceExportConflict = "Conflict"
454+
)
475455
```
476456
```yaml
477457
apiVersion: multicluster.k8s.io/v1alpha1
@@ -483,9 +463,11 @@ status:
483463
conditions:
484464
- type: Ready
485465
status: "True"
466+
message: "Service export is ready"
486467
lastTransitionTime: "2020-03-30T01:33:51Z"
487-
- type: InvalidService
488-
status: "False"
468+
- type: Valid
469+
status: "True"
470+
message: "Service export is valid"
489471
lastTransitionTime: "2020-03-30T01:33:55Z"
490472
- type: Conflict
491473
status: "True"
@@ -704,7 +686,8 @@ this cluster.
704686
complicate deployments by even attempting to stretch them across clusters.
705687
Instead, regular `ExternalName` type `Services` should be created in each
706688
cluster individually. If a `ServiceExport` is created for an `ExternalName`
707-
service, an `InvalidService` condition will be set on the export.
689+
service, a condition type `Valid` with a `false` status will be set on the
690+
`ServiceExport`.
708691

709692
#### ClusterSetIP
710693

0 commit comments

Comments
 (0)