Merge order for template assembly

[jandubois]

I've been working on the basedOn feature that I've discussed previously at #2520 (reply in thread).

A template can take a list of other (base) templates to provide default settings:

basedOn:
- my-settings.yaml
- template://fedora

param:
  …

provision:
  …

Each base template can recursively be basedOn additional templates.

It already works quite nicely, maintaining YAML comments from both the instance and the base templates as appropriate.

I do want to use the same mechanism during instance start for merging defaults.yaml and override.yaml (the basedOn mechanism is only executed during instance create and the assembled template is then stored in the instance directory).

The existing merge algorithm is basically:

• Scalar values are picked from the highest level config that sets them.
• List values are concatenated, with the highest level on top.

There are some exceptions to that (e.g. dns lists work like scalar values and are not appended).

Both mounts and networks are combined in reverse order (lowest to highest). I believe I did this because both use a shared key (mounts[].location and networks[].interface) to update the lower priority settings with higher priority ones later in the list (which are then discarded)¹.

Otherwise the order of mounts and networks shouldn't really matter (except maybe for the buggy behaviour of overlapping reverse-sshfs mounts).

I had assumed that we also concatenated the provision and probes list in reverse order, so that the highest level scripts run last, and can adapt to the lower level one running before. But we don't actually do so.

Do you think anyone relies on a provisioning script from override.yaml to run before the provisioning scripts of the regular template? I can't think of any of our bundled scripts that would be configurable by another script running first.

So here are my questions:

1. Can we change the order of mounts and networks as long as the combining mechanism on the shared key continues to work the same way?

2. Should we reverse the order of combined provision and probes scripts?

Footnotes

1. I noticed that for consistency additionalDisks should probably be treated the same way, with additionalDisks[].name being the shared key, even though I don't really see much of a use case for it. ↩

[jandubois]

2. Should we reverse the order of combined provision and probes scripts?

To provide an example, I think it should be possible to write a wordpress.yaml template like this (untested):

basedOn: template://k3s

provision:
- file: template://install/helm
- script: |
    helm repo add bitnami https://charts.bitnami.com/bitnami
    helm repo update bitnami
    helm install wordpress bitnami/wordpress \
        --set service.type=NodePort \
        --set volumePermissions.enabled=true \
        --set mariadb.volumePermissions.enabled=true

This will only work if the provisioning script from template://k3s runs before the provisioning scripts from the main template.

I know that there are workarounds, like relying on the fact that user scripts run after all the system scripts, but the principle of least surprise demands to do the right thing by default.

[jandubois]

both use a shared key (mounts[].location and networks[].interface) to update the lower priority settings with higher priority ones

I realized that mounts[].location used to be a unique key when this was implemented. But since then we have added mounts[].mountPoint, which is now the unique key: you can mount the same location under 2 different mount points, with different attributes (e.g. writable).

This means combining multiple mounts into a single setting, just because they use the same location, is now potentially wrong.

So I propose switching to using mounts[].mountPoints as the combining key in the future.

The only issue is that somebody might have used the current algorithm to move the default mount location for the home directory to a different mount point in override.yaml, e.g.

mounts:
- location: '~'
  mountPoint: /home/guest

Right now this would modify the existing mount. With the proposed change, this would create an additional mount. While not ideal, I don't think this should break anything (famous last words alert!).

So I guess I have a 3rd question:

3. Should we switch the mounts combining key from location to mountPoint?