feat(helpers): support custom datasource vendor merge strategies

[goldberl]

Proposed Commit Message

feat(helpers): support custom datasource vendor merge strategies

When deploying a MAAS node with custom user-data, top-level lists
in vendor-data (e.g., `write_files`) are dropped if user-data defines
the same keys. This breaks networking by dropping the MAAS Netplan
configuration (`/etc/netplan/50-maas.yaml`).

To fix this without affecting other cloud providers, this change
allows datasources to specify custom merge strategies:

- `ConfigMerger` checks the active datasource (`self._ds`) for a
  `vendor_merge_how` attribute when loading vendor cloud config.
- `DataSourceMAAS` sets `vendor_merge_how` to append list values.

Signed-off-by: Leah Goldberg <leah.goldberg@canonical.com>

Fixes GH-6268
LP: #2158442

Additional Context

This PR fixes an issue where top-level lists in vendor-data (such as write_files) are silently dropped when user-data defines the same keys, which breaks MAAS deployments by wiping out the Netplan network configuration (/etc/netplan/50-maas.yaml).

To resolve this without altering global merge behavior across other cloud providers, ConfigMerger now inspects the active datasource for a vendor_merge_how attribute. DataSourceMAAS sets this attribute to list(append)+dict(no_replace,recurse_list)+str(), ensuring MAAS-generated vendor lists are appended to user lists.

For example:

user-data

{
    "write_files": [
        {"path": "/leah.txt", "content": "hello leah", "permissions": "0644"}
    ]
}

vendor-data

{
    "write_files": [
        {"path": "/etc/netplan/50-maas.yaml", "content": "network:\n...", "permissions": "0600"}
    ],
    "runcmd": ["netplan apply"]
}

The current way of merging is:

{
    "write_files": [
        {"path": "/leah.txt", "content": "hello leah", "permissions": "0644"}
    ],
    "runcmd": ["netplan apply"] 
}

Notice how the write_files from the vendor-data is ignored since the user-data already defined write_files.

This PR would change the merge for DataSourceMAAS to be:

{
    "write_files": [
        {"path": "/leah.txt", "content": "hello leah", "permissions": "0644"},
        {"path": "/etc/netplan/50-maas.yaml", "content": "network:\n...", "permissions": "0600"} 
    ],
    "runcmd": ["netplan apply"]
}

This ensures list values are appended instead of dropped.

Test Steps

How to reproduce the bug

1. Deploy MAAS (3.4 or 3.6 - deb or snap) and add a VM.
2. Customize the VM network so it's non-default (e.g. add a VLAN).

3. Deploy the machine to memory with a custom cloud-init config:

#cloud-config

write_files:
  - path: /dave.txt
    content: "hello"
    owner: root:root
    permissions: '0644'

4. Once the VM is deployed, note the network config. It will only have the PXE config and drop the custom config you added.

Actual behavior

Name	State	IPv4	IPv6	Type	Snapshots
octopus-memory	RUNNING	10.239.17.2 (enp5s0)		VIRTUAL-MACHINE	0

The deployed machine only has the PXE interface (enp5s0) configured.

Expected behavior

Name	State	IPv4	IPv6	Type	Snapshots
octopus-memory	RUNNING	10.239.17.2 (enp5s0) 10.20.0.1 (enp5s0.100)		VIRTUAL-MACHINE	0

The expected behavior is for both the PXE interface (enp5s0) and the MAAS-configured VLAN interface (enp5s0.100) to remain configured after deployment.

How to test this fix

Note: I tested this on MAAS 3.5.12 (snap) which uses Ubuntu 22.04 (Jammy).

1. Create a custom image with packer-maas that includes this cloud-init patch (or you can download this one).
2. Upload it to your MAAS environment.

maas $PROFILE boot-resources create \
    name='custom/packer-custom-ubuntu' \
    title='Ubuntu 22.04 (patched: cloud-init vendor-merge)' \
    architecture='amd64/generic' \
    filetype='tgz' \
    content@=ubuntu-jammy-cloudinit-merge-user-vendor-fix.tar.gz

3. Deploy a VM with the custom image to memory and the custom cloud config.
4. SSH into machine and check that networking is set up properly.

You should see networking is set up properly now:

ubuntu@octopus-memory:~$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp5s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:16:3e:2d:fb:b3 brd ff:ff:ff:ff:ff:ff
    inet 10.239.17.2/24 brd 10.239.17.255 scope global enp5s0
       valid_lft forever preferred_lft forever
    inet6 fe80::216:3eff:fe2d:fbb3/64 scope link 
       valid_lft forever preferred_lft forever
3: enp5s0.100@enp5s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 00:16:3e:2d:fb:b3 brd ff:ff:ff:ff:ff:ff
    inet 10.20.0.1/24 brd 10.20.0.255 scope global enp5s0.100
       valid_lft forever preferred_lft forever
    inet6 fe80::216:3eff:fe2d:fbb3/64 scope link 
       valid_lft forever preferred_lft forever

Related Links

• [docs]: Incomplete and misleading guidance on merging vendor-data #6268
• LP 2158442: custom cloud-config conflicts with MAAS-generated vendor-data in deploy-to-memory workflows
• Replaces fix(helpers): append vendor cloud-config lists instead of dropping them #6933

Merge type

• Squash merge using "Proposed Commit Message"
• Rebase and merge unique commits. Requires commit messages per-commit each referencing the pull request number (#<PR_NUM>)