-
Notifications
You must be signed in to change notification settings - Fork 19
interface: experimental: status back-reporting #255
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.
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
interface: experimental: status back-reporting #255
Conversation
Signed-off-by: michaelawyu <chenyu1@microsoft.com>
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
Signed-off-by: michaelawyu <chenyu1@microsoft.com>
Signed-off-by: michaelawyu <chenyu1@microsoft.com>
Signed-off-by: michaelawyu <chenyu1@microsoft.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
btw, it occurred to me that although we don't use v1 work, it's better to copy all the fields there
| type ReportBackStrategyType string | ||
|
|
||
| const ( | ||
| // ReportBackStrategyTypeDisabled disables status back-reporting from the member clusters. | ||
| ReportBackStrategyTypeDisabled ReportBackStrategyType = "Disabled" | ||
|
|
||
| // ReportBackStrategyTypeMirror enables status back-reporting by | ||
| // copying the status fields verbatim to the corresponding objects on the hub cluster side. This is | ||
| // only performed when the placement object has a scheduling policy that selects exactly one | ||
| // member cluster (i.e., a pickFixed scheduling policy with exactly one cluster name, or | ||
| // a pickN scheduling policy with the numberOfClusters field set to 1). If multiple member clusters | ||
| // are selected, KubeFleet will fall back to the ReplicatePerCluster strategy, as described below. | ||
| ReportBackStrategyTypeMirror ReportBackStrategyType = "Mirror" | ||
|
|
||
| // ReportBackStrategyTypeReplicatePerCluster enables status back-reporting by copying | ||
| // the status fields verbatim via the Work API on the hub cluster side. Users may look up | ||
| // the status of a specific resource applied to a specific member cluster by inspecting the | ||
| // corresponding Work object on the hub cluster side. | ||
| ReportBackStrategyTypeReplicatePerCluster ReportBackStrategyType = "ReplicatePerCluster" | ||
| ) | ||
|
|
||
| // ReportBackStrategy describes how to report back the resource status from member clusters. | ||
| type ReportBackStrategy struct { | ||
| // Type dictates the type of the report back strategy to use. | ||
| // | ||
| // Available options include: | ||
| // | ||
| // * Disabled: status back-reporting is disabled. This is the default behavior. | ||
| // | ||
| // * Mirror: status back-reporting is enabled by copying the status fields verbatim to | ||
| // the corresponding objects on the hub cluster side. This is only performed when the placement | ||
| // object has a scheduling policy that selects exactly one member cluster (i.e., a pickFixed | ||
| // scheduling policy with exactly one cluster name, or a pickN scheduling policy with the | ||
| // numberOfClusters field set to 1). If multiple member clusters are selected, KubeFleet will | ||
| // fall back to the ReplicatePerCluster strategy. | ||
| // | ||
| // * ReplicatePerCluster: status back-reporting is enabled by copying the status fields verbatim via the Work API | ||
| // on the hub cluster side. Users may look up the status of a specific resource applied to a | ||
| // specific member cluster by inspecting the corresponding Work object on the hub cluster side. | ||
| // | ||
| // +kubebuilder:default=Disabled | ||
| // +kubebuilder:validation:Enum=Disabled;Mirror;ReplicatePerCluster | ||
| // +kubebuilder:validation:Required | ||
| Type ReportBackStrategyType `json:"type"` | ||
| } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can this be spread out in a different way
const (
// ReportBackStrategyTypeDisabled disables status back-reporting from the member clusters.
ReportBackStrategyTypeDisabled ReportBackType = "Disabled"
// will copy the status back
ReportBackStrategyTypeMirror ReportBackType = "Copy"
)
(
// Propagate to the original resource
ReportBackPropagateTypeOriginal ReportBackPropagateType = "Original"
// Propagate to work only
ReportBackPropagateTypeWork ReportBackPropagateType = "Work"
)
// ReportBackStrategy describes how to report back the resource status from member clusters.
type ReportBackStrategy struct {
// Type dictates the type of the report back type to use.
Type ReportBackType `json:"type"`
// Type dictates the type of the report back strategy to use.
Type ReportBackPropagateType `json:"type"`
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, that sounds great; let me make the edits
…o api/experimental-status-backport-support
Signed-off-by: michaelawyu <chenyu1@microsoft.com>
Signed-off-by: michaelawyu <chenyu1@microsoft.com>
Signed-off-by: michaelawyu <chenyu1@microsoft.com>
Signed-off-by: michaelawyu <chenyu1@microsoft.com>
Description of your changes
This PR adds some experimental API changes that allow status back-reporting.
I have:
make reviewableto ensure this PR is ready for review.How has this code been tested
N/A
Special notes for your reviewer
N/A