ResourceInterpreterCustomization for Prune

[a7i]

What would you like to be added:
Currently, Prune is only supported for built-in, and there are use-cases where we could use Prune for custom resources.

Why is this needed:
this blog does a good job of covering the interpreters and based on the image, we may want to exclude labels/annotations before Work is created

[XiShanYongYe-Chang]

@a7i Thanks for your feedback, I think this is an interesting feature point.

Before we start discussing how to do this, let's invite some ideas from people who might be interested in this.

/cc @chaunceyjiang @whitewindmills @RainbowMango @yike21 @iawia002

[XiShanYongYe-Chang]

we may want to exclude labels/annotations before Work is created

Hi @a7i I'd like to know under what circumstances this would be necessary. Because after communicating with @RainbowMango, I realized that retain can be used to handle the conflict between the Karmada control plane and member clusters.

[a7i]

Prune would be to strip certain fields (e.g. label) from being propagated. With Retain, the label still goes to the member cluster but the value is essentially ignored.

One use-case is that we use a label to determine if a workload should be duplicated in all member clusters or not (the label is matched by the policy labelSelector). There is no need for this label to get propagated to the member clusters.

[XiShanYongYe-Chang]

Thanks for the use case. I think it makes sense.
cc @RainbowMango

[RainbowMango]

It seems to make sense, I'll get back to it later.

[whitewindmills]

One use-case is that we use a label to determine if a workload should be duplicated in all member clusters or not (the label is matched by the policy labelSelector). There is no need for this label to get propagated to the member clusters.

make sense.

[RainbowMango]

One use-case is that we use a label to determine if a workload should be duplicated in all member clusters or not (the label is matched by the policy labelSelector). There is no need for this label to get propagated to the member clusters.

It seems a reasonable use case that you label resources and let PropagationPolicy match them.
But I have several questions:

1. I know there is no need for this label to get propagated, but that doesn't do any harm, right?
2. Can we prune the unnecessary label by OverridePolicy? I'm wondering if this is an option.

[chaunceyjiang]

🤔 It seems that using OverridePolicy can cove this.

[a7i]

Using Lua gives more flexibility and control than PlaintextOverrider but at the moment, using a ClusterOverridePolicy will work for us. Thank you

/close

[karmada-bot]

@a7i: Closing this issue.

In response to this:

Using Lua gives more flexibility and control than PlaintextOverrider but at the moment, using a ClusterOverridePolicy will work for us. Thank you

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[RainbowMango]

Oh, seems you like Lua.

But, by the way, the LabelAnnotationOverrider and LabelAnnotationOverrider might be more straightforward than PlaintextOverrider.

[a7i]

It's growing on me :)