Feat: defining value by CEL in overriders

[Patrick0308]

What would you like to be added: Supporting defining value by CEL in overriders. And the target k8s resource is been exposed by self object in CEL expression.

• Plaintext Overrider:

      plaintext:
        - path: /data/example
          operator: replace
          expression: self.spec.data

• Label Overrider:

      labelsOverrider:
        - operator: add
           expression: 
             bar: self.label['arr']

• Annotation Overrider:

      annotationsOverrider:
        - operator: add
           expression: 
             bar: self.labels['arr']

• Image Overrider:

      imageOverrider:
        - component: Registry
          operator: add
          expression: self.annotations['registry']

• Command Overrider:

      commandOverrider:
        - containerName: myapp
          operator: add
          expression:
            - self.annotations['arg1']

About multi override rules

Previous override rules modify the self object

  resourceSelectors:
    - apiVersion: apps/v1
      kind: Deployment
      name: nginx
  overrideRules:
    - targetCluster:
        clusterNames:
          - member1
      overriders:
        labelsOverrider:
          - operator: replace
             value:
              env: member1-env
    - targetCluster:
        clusterNames:
          - member2
      overriders:
        labelsOverrider:
          - operator: replace
             value:
              env: member2-env
    - targetCluster:
        clusterNames:
          - member1
          - member2
      overriders:
        labelsOverrider:
          - operator: add
             expression:
               env1:  self.label['env']  ## env1 label's value is member1-env, member2-env in member1 cluster and member2 cluster.

Why is this needed: At https://github.com/karmada-io/karmada/issues/4739, we discussed the feature of variables on OverridePolicy. And we need a expression language to refer the variables.

CEL is a single line language. It's simple to written in yaml config . And It's been used on k8s validation.

[Patrick0308]

https://playcel.undistro.io/ This is a cel playground.

[chaunceyjiang]

A question: is 'self' referring to the OP themselves or the object chosen by the OP?

[Patrick0308]

A question: is 'self' referring to the OP themselves or the object chosen by the OP?

The k8s resource in a cluster chosen by the OP

[chaunceyjiang]

I believe this is a very good solution.

My only concern at the moment is whether Karmada's simultaneous support for Lua and CEL will increase the learning cost for end users.

[Patrick0308]

Lua is not good for expression evaluation. If you only wanna using Lua on karmada, pls adding a ScriptOverrider feature. It's another request. ScriptOverrider's example on above:

overrideRules:
    - targetCluster:
        clusterNames:
          - member1
          - member2
      overriders:
        scriptOverrider:
           inlineString: >
               function modifyObj(self)
                    //...
               end
           configMap:
               name: scripts1
               key: test.lua

My only concern at the moment is whether Karmada's simultaneous support for Lua and CEL will increase the learning cost for end users.

CEL's learning curve is smooth. A simple expression is easy.

[RainbowMango]

What problems can be solved by providing the support of CEL? Or can it improve the user experience? Do we have a concrete use case?

[Patrick0308]

@RainbowMango Pls see https://github.com/karmada-io/karmada/issues/4739#issuecomment-2017180616 and the context of this issue.

[Patrick0308]

@XiShanYongYe-Chang @RainbowMango @chaunceyjiang Any idea

[RainbowMango]

Sorry, I don't have a chance to dive into it yet. This issue is still in my queue. :( In the meantime, glad to talk at the community meeting.

[XiShanYongYe-Chang]

Hi @Patrick0308, I looked at the current issue and the #4739. The features described by both of them are, I understand, two parallel features that extend the OP. Both focus on the way values are obtained in the op.

From the description and comments, both features are amazing, but We'd like to know more about the motivation behind the features, that is, what their user stories are. Maybe we can discuss these two issues in the community meeting to move forward.