Patch strategy

    KubeVela provides a series of patching strategies to help resolve conflicting issues. When writing patch traits and workflow steps, you can use these patch strategies to solve conflicting values. Note that the patch strategy is not an official capability provided by CUE, but an extension developed by KubeVela.

    Let’s write an env-patch trait to show how to use these patch strategies.

    If you want to add multiple environment variables for a specific container, you can use the annotation to find the container. In this case, KubeVela will merge these environment variables by default. This means that patchKey cannot handle duplicate fields.

    Apply the following definition to your cluster:

    Use the above myenv trait in your application:

    1. apiVersion: core.oam.dev/v1beta1
    2. kind: Application
    3. metadata:
    4. name: webservice-app
    5. spec:
    6. components:
    7. - name: express-server
    8. type: webservice
    9. properties:
    10. image: crccheck/hello-world
    11. env:
    12. - name: OLD
    13. value: old
    14. traits:
    15. - type: myenv
    16. properties:
    17. env:
    18. NEW: new
    1. spec:
    2. containers:
    3. - env:
    4. - name: OLD
    5. value: old

    After using the myenv patch trait, the env in the application is like:

    1. spec:
    2. containers:
    3. - env:
    4. - name: OLD
    5. value: old
    6. - name: NEW
    7. value: new

    Finally, we can see that the application’s env contains two environment variables: OLD=old and NEW=new.

    You can use the +patchStrategy=retainKeys annotation if you want to be able to override duplicate values while merging variables.

    The strategy of this annotation is similar to the Kubernetes official [retainKeys](https://kubernetes.io/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch/#use-strategic-merge-patch- to-update-a-deployment-using-the-retainkeys-strategy) strategy.

    Use the above myenv trait in your application:

    1. kind: Application
    2. metadata:
    3. name: webservice-app
    4. spec:
    5. components:
    6. - name: express-server
    7. type: webservice
    8. properties:
    9. image: crccheck/hello-world
    10. env:
    11. - name: OLD
    12. value: old
    13. - name: OLD2
    14. value: old2
    15. traits:
    16. - type: myenv
    17. properties:
    18. env:
    19. NEW: new
    20. OLD2: override

    Before using the myenv patch trait, the env in the application is like:

    1. spec:
    2. containers:
    3. - env:
    4. - name: OLD
    5. value: old
    6. - name: OLD2
    7. value: old2
    1. spec:
    2. containers:
    3. - env:
    4. - name: OLD
    5. value: old
    6. - name: OLD2
    7. - name: NEW
    8. value: new

    Finally, we can see that the application’s env contains three environment variables: , OLD2=override and NEW=new.

    If you wish to replace the entire env array directly, you can use the +patchStrategy=replace annotation.

    Use the above myenv trait in your application:

    1. apiVersion: core.oam.dev/v1beta1
    2. kind: Application
    3. metadata:
    4. name: webservice-app
    5. spec:
    6. components:
    7. - name: express-server
    8. type: webservice
    9. properties:
    10. image: crccheck/hello-world
    11. env:
    12. - name: OLD
    13. value: old
    14. - name: OLD2
    15. value: old2
    16. traits:
    17. - type: myenv
    18. properties:
    19. env:
    20. NEW: replace

    Before using the myenv patch trait, the env in the application is like:

    1. spec:
    2. containers:
    3. - env:
    4. - name: OLD
    5. value: old
    6. - name: OLD2
    7. value: old2

    After using the myenv patch trait, the env in the application is like:

    1. spec:
    2. containers:
    3. - env:
    4. - name: NEW

    Finally, we can see that the application’s env contains one environment variable: .