Mutation: introduce "priority" parameter to enforce ordering of mutations

[mmirecki]

The mutations are always applied as an ordered list to ensure the same mutation result. It can be however difficult for the user to predict this order and therefore the outcome.
I was asked what the result of the following mutations would be:

Mutation A:

    location: "spec.containers[name:networking]"
    parameters:
      assign:
        value:
          name: "networking"
          image: "myrepo/myimage"
          ...
          command:
          - init

Mutation B:

    location: "spec.containers[name:*].imagePullPolicy"
    parameters:
      assign
           value: “Always”

The mutations add a sidecar and modify the imagePullPolicy. Depending on the order of the mutations, the created sidecar will, or will not have the imagePullPolicy mutation applied.

A solution for this could be an additional "priority" parameter, which would allow the user to have influence on the order of applying the mutations.
The mutations would be sorted by "priority" first. The parameter can be optional, elements with no "priority" specified being the last to be applied.

For example, modifying the above example, we could give mutation B a higher priority, therefore ensuring that the new sidecar has no imagePullPolicy:

Mutation A:

    location: "spec.containers[name:networking]"
    parameters:
      priority: 10
      assign:
        value:
          name: "networking"
          image: "myrepo/myimage"
          ...
          command:
          - init

Mutation B:

    location: "spec.containers[name:*].imagePullPolicy"
    parameters:
      priority 100
      assign
           value: “Always”

[maxsmythe]

Is mutation A supposed to have a different imagePullPolicy than mutation B?

I agree that having some kind of ordering customization is inevitable. Numbered priority makes sense to me, but makes a lot of people shudder (perhaps bad memories from other priorty-based-ordering solutions?).

It's worth getting feedback on the exact mechanism just to see if anyone has any better ideas.

[maxsmythe]

I believe there is some discussion around ordered mutations on some of the older mutation design docs (linked from the docs directory in this repo.

[mmirecki]

Yes, the doc say:

**Custom Ordering**
If we want to have custom ordering, we could create a field that is used as the primary sort criteria, followed by GKNN. This could be an integer for intuitive sort ordering. Note that for conflicting mutations, the most recently applied mutation wins.
There may be other ways of customizing order that may be more natural for admins, so further design effort may be helpful here. Custom ordering was not part of the MVP, but it seems a likely feature request.

This issue is the prophesied feature request with some further design effort.

[chewong]

I can take a look at this issue if no one is working on it

[maxsmythe]

Do we have a use case for this yet? I am slightly concerned about user complexity unless we know there is a need. Also, would be good to see a mock API for this before we commit to coding it to be sure we agree on direction. Probably just pasting some mock resources in this issue is fine IMO

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 14 days if no further activity occurs. Thank you for your contributions.

[kfox1111]

I've got a use case....

Say you want to create a set of mutations that:

1. only runs on pods with volumes of type csi with a driver name of foo
2. adds a sidecar to the pod using properties from the volumes attributes
3. add an additional volume to the pod
4. switch the csi driver volume to be an emptydir

2 and 3 need to happen before 4 or else they wont be able to solve their constraint from 1.

[kfox1111]

Could it be simpler to just order the list based on the .metadata.name property?