can let Karmada only auto generate Resource Binding but not work？

[mkloveyy]

Is there a config can support this:
Let Karmada auto generate Resource Binding but not create work.
Like Part of --skipped-propagating-apis

Environment:

• Karmada version: v1.4.1-with-lua
• Kubernetes version: 1.19
• Others:

[XiShanYongYe-Chang]

If work is not created, resources will not be synchronized in the member cluster.

Can you share your use case?

[mkloveyy]

@XiShanYongYe-Chang Thanks for you help!

Here is our user case:
In karmada，we use op to maintain zone-related and cluster's diff deploy steps info and need to update them first in every deploy. So when user update resource template, we want to update op first before karmada schedule resource template update to works.

Currently we consider use webhook to listen update events with resource template and update op first then allow the update by karmada scheduling continue.

Hope you can give us a better proposal. Thanks a lot!

[mkloveyy]

Or is there any way to force update overriders in op before resourceBinding update works.
Maybe implement cluster's diff deploy steps info in retain/prune hook in an custom ResourceInterpreterWebhook?

[XiShanYongYe-Chang]

Sorry, I don't understand your use case. Do you need to modify op every time you modify a resource template?

[mkloveyy]

Sorry, I don't understand your use case. Do you need to modify op every time you modify a resource template?
Yes.

This is part of our demo op:

apiVersion: policy.karmada.io/v1alpha1
kind: OverridePolicy
spec:
  overrideRules:
    - targetCluster:
        clusterNames:
          - zone-x
      overriders:
        plaintext:
          - path: /spec/strategy/canary/steps
            operator: add
            value:
              - properties:
                  delay: "-1"
                  pull: "false"
                type: Fort
              - properties:
                  delay: "-1"
                  pull: "true"
                type: Fort
              - properties:
                  delay: "-1"
                  maxUnavailable: "0"
                  replicas: 50%
                  timeout: "5"
                type: Batch
              - properties:
                  delay: "-1"
                  maxUnavailable: "0"
                  replicas: 100%
                  timeout: "5"
                type: Batch
    - targetCluster:
        clusterNames:
          - zone-z
      overriders:
        plaintext:
          - path: /spec/strategy/canary/steps
            operator: add
            value:
              - properties:
                  delay: "-1"
                  pull: ""
                type: Fort
              - properties:
                  delay: "-1"
                  pull: ""
                type: Fort
              - properties:
                  delay: "-1"
                  maxUnavailable: "0"
                  replicas: 50%
                  timeout: "5"
                type: Batch
              - properties:
                  delay: "-1"
                  maxUnavailable: "0"
                  replicas: 100%
                  timeout: "5"
                type: Batch

We need to specify /spec/strategy/canary/steps for our custom resource template in different member clusters, but /spec/strategy/canary/steps need to change every time when resource template updated and before works updated.

Is it not suitable to put /spec/strategy/canary/steps specification into op？Maybe retain/prune hook in an custom ResourceInterpreterWebhook is better?

[XiShanYongYe-Chang]

Maybe you can use this field to do that:

karmada/pkg/apis/policy/v1alpha1/propagation_types.go

Lines 94 to 104 in 7f9dd0f

	// DependentOverrides represents the list of overrides(OverridePolicy)
	// which must present before the current PropagationPolicy takes effect.
	//
	// It used to explicitly specify overrides which current PropagationPolicy rely on.
	// A typical scenario is the users create OverridePolicy(ies) and resources at the same time,
	// they want to ensure the new-created policies would be adopted.
	//
	// Note: For the overrides, OverridePolicy(ies) in current namespace and ClusterOverridePolicy(ies),
	// which not present in this list will still be applied if they matches the resources.
	// +optional
	DependentOverrides []string `json:"dependentOverrides,omitempty"`

[XiShanYongYe-Chang]

Maybe we can talk in slack or wechat.

[mkloveyy]

Maybe we can talk in slack or wechat.

Agreed. Where to join karmada's wechat group？

[XiShanYongYe-Chang]

Refer to the bottom of this link: https://mp.weixin.qq.com/s?__biz=MzIzNzU5NTYzMA==&mid=2247497323&idx=1&sn=4dd7eb1966c7923a3317d036a385fd52#rd

[mkloveyy]

Ok. I've requested.Thx!

[mkloveyy]

// A typical scenario is the users create OverridePolicy(ies) and resources at the same time,
// they want to ensure the new-created policies would be adopted.

What's the behavior if updating op and resources at the same time？Will it still ensure the new-updated policies be adopted first？

[XiShanYongYe-Chang]

What's the behavior if updating op and resources at the same time？Will it still ensure the new-updated policies be adopted first？

For apiserver, there is no real at the same time, which will mean some chance that either resource template is processed before op is processed, or op is processed before resource template is processed, but I think the final reconcile result will be consistent.

[mkloveyy]

Sry for my expression.
I wonder if we update resource first then update op, will this config ensure op's newest update to be adopted to member clusters？
And if above is true，how many times will member clusters resource be updated？

[mkloveyy]

@XiShanYongYe-Chang I've read the source code related to DependentOverrides. ResourceDetector only checks if dependent OverridePolicies all exist. So as document says, it can only ensure the new-created policies would be adopted but not updated.
So we seems to go back to find another hook to implement our demands.

[mkloveyy]

Refer to the bottom of this link: https://mp.weixin.qq.com/s?__biz=MzIzNzU5NTYzMA==&mid=2247497323&idx=1&sn=4dd7eb1966c7923a3317d036a385fd52#rd

I've requested and hope to help to approve soon. Thanks a lot!

[XiShanYongYe-Chang]

I wonder if we update resource first then update op, will this config ensure op's newest update to be adopted to member clusters？
And if above is true，how many times will member clusters resource be updated？

bindingController watch op event, it'll take effect after reconcile, which shouldn't be long.

[XiShanYongYe-Chang]

I've requested and hope to help to approve soon. Thanks a lot!

Just add me: 15251838160

[mkloveyy]

After deeply communicating with @XiShanYongYe-Chang，we found that ReviseReplicas can implement our demands. Thanks for @XiShanYongYe-Chang help!

By the way, I suggest to change ReviseReplicas to maybe ReviseObject as it can revise not only replicas but also other workload fields.

[XiShanYongYe-Chang]

By the way, I suggest to change ReviseReplicas to maybe ReviseObject as it can revise not only replicas but also other workload fields.

The original purpose of ReviseReplicas operation is to modify the replicas in the object based on the replicas in the input parameter. You can also make some additional modifications based on replicas, which is equivalent to an extended operation.