-
Notifications
You must be signed in to change notification settings - Fork 819
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
ResourceInterpreterCustomization: support multiple per Kind and operation #4851
Comments
Code path that enforces one per kind/operation: https://github.com/karmada-io/karmada/blob/master/pkg/webhook/resourceinterpretercustomization/helper.go#L29C67-L46 |
If the same kind supports multiple ResourceInterpreterCustomization configurations, the execution sequence may affect the final result. What do you think about this? Invite @chaunceyjiang to have a look. |
We could start with "sort ResourceInterpreterCustomization by name", but something like |
Yes, the reason we introduce this constraint is that if multiple operations perform mutually exclusive modifications to the same resource, the resulting state may be unpredictable. |
---
apiVersion: config.karmada.io/v1alpha1
kind: ResourceInterpreterCustomization
metadata:
name: retain-data
spec:
customizations:
retention:
luaScript: |
function Retain(desiredObj, observedObj)
# A || B , priority A > B
# rule A
if desiredObj.data ~= nil then
if desiredObj.data["tls.crt"] ~= nil then
desiredObj.data = observedObj.data
return desiredObj
end
end
# rule B
if desiredObj.type == "kubernetes.io/service-account-token" then
desiredObj.data = observedObj.data
end
return desiredObj
end
target:
apiVersion: v1
kind: Secret An optional way to do this is to make one single ResourceInterpreterCustomization more complex to support multiple operations. |
Hi @yike21 Does Lua support this? |
The problem may still exist. For example, if resource
Introducing priority maybe possible, but will the management of priority bring new complexity to users? For example, user
Wouldn't random solve the problem of the effect being overwritten? |
Can you elaborate on this benefit, or what's delicious in addition to this benefit. |
We can write some logic in lua to make the operation return early (this is not flexible), for example:
And Lua doesn't support configuration policy. |
Ok @yike21 Thanks I understand that this is actually a requirement for users. After all, lua scripts are written by users. |
That is what we ended up doing (putting everything in one and using conditional statement), but as mentioned in the Issue, it would be nice to split it up to separate the logic. |
Ask @RainbowMango to help take a look. |
Before talking about What's the pain point for now? Do not want to write and maintain a large configuration? |
In the example given in the Issue, we have to add bunch of conditional statements to switch based on secret type to retain respective fields.
That's exactly correct. |
Yeah, I can tell the conditional statements from the example yaml above mentioned by @yike21. But even split them into several ResourceInterpreterCustomizations, you still need to maintain these statements, in addition, you have to manage the activation order. Is it worth doing that? |
Currently, the logic prevents having two ResourceInterpreterCustomization for the same target Kind.
Take the scenario below:
Note that they're both operation
retention
andtarget.Kind: Secret
This results in error:
What would you like to be added:
Ability to support multiple ResourceInterpreterCustomization for same kind and operation.
Why is this needed:
This allows for smaller lua scripts per ResourceInterpreterCustomization
The text was updated successfully, but these errors were encountered: