Skip to content
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

add a feature-gate for Lazy Reconcile feature #4564

Closed
wants to merge 1 commit into from
Closed
Changes from all commits
Commits
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
5 changes: 5 additions & 0 deletions pkg/features/features.go
Original file line number Diff line number Diff line change
Expand Up @@ -40,6 +40,10 @@ const (

// MultiClusterService indicates if enable multi-cluster service function.
MultiClusterService featuregate.Feature = "MultiClusterService"

// PolicyLazyReconcile indicates if enable Lazy Reconcile feature for Propagation Policy.
// If enabled, the effective time of policy modification will be delayed until the resource template is modified.
PolicyLazyReconcile featuregate.Feature = "PolicyLazyReconcile"
)

var (
Expand All @@ -54,6 +58,7 @@ var (
CustomizedClusterResourceModeling: {Default: true, PreRelease: featuregate.Beta},
PolicyPreemption: {Default: false, PreRelease: featuregate.Alpha},
MultiClusterService: {Default: false, PreRelease: featuregate.Alpha},
PolicyLazyReconcile: {Default: false, PreRelease: featuregate.Alpha},
Copy link
Member

Choose a reason for hiding this comment

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

Why is there only one global switch? Will you also introduce related fields in PP next?

What I mean is, can the system have both an immediately effective PP and a Lazy Reconcile PP at the same time?

Copy link
Member

Choose a reason for hiding this comment

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

Because if there's only one of two options, then assuming all future defaults are Lazy Reconcile, most users would refuse to upgrade due to their lack of experience with Lazy Reconcile.

Copy link
Member

Choose a reason for hiding this comment

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

+1
lazy should not be the default behavior.

Copy link
Member Author

Choose a reason for hiding this comment

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

Lazy is not the default behavior as PolicyLazyReconcile{Default: false}

What chaunceyjiang mean is that it is better to add a filed to Policy to control the the effect strategy.

Copy link
Member

Choose a reason for hiding this comment

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

What I mean is: It would be best if these two behaviors could coexist in the karmada.

Copy link
Member

Choose a reason for hiding this comment

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

I still have one question I don't fully understand, which is: if a resource has not changed but the PP has changed, then this resource will continue to use the old PP. If a rescheduling happens at this time, should the scheduler use the old PP or the new PP? If it uses the new PP, then that behavior would be somewhat inconsistent with our expected behavior.
Our expectation is that the new PP would only be applied if the resource itself has changed.

}
)

Expand Down
Loading