Comment 2 for bug 2011298

Here is sanitized data to match the description from earlier:

kernel command line:

initrd=initrd.cpio initrd=squashfs rootfstype=squashfs root=/squashfs ip=1.2.3.4::1.2.3.1:255.255.255.248::eno1:off:1.1.1.1 overlayroot=tmpfs:recurse=0 systemd.clock-usec=1678710046000000 ds=nocloud-net;s=https://cloud-init.sanitized/

/etc/netplan/50-cloud-init.yaml (which I generate separately)

network:
  version: 2
  ethernets:
    eno1:
      addresses: []
      dhcp4: false
      dhcp6: false
      match:
        macaddress: 11:22:33:44:55:66
    eno2:
      addresses: []
      dhcp4: false
      dhcp6: false
      match:
        macaddress: 11:22:33:44:55:67
  bonds:
    bond0:
      addresses:
        - 1.2.3.4/29
        - 1.2.3.5/29
        - 1.2.3.6/29
      routes:
        - to: default
          via: 1.2.3.1
      nameservers:
        addresses:
          - 1.1.1.1
      interfaces:
        - eno1
        - eno2
      parameters:
        mode: active-backup
        primary: eno1
        fail-over-mac-policy: active
        arp-validate: active
        arp-interval: 5000
        arp-ip-targets:
          - 1.2.3.1

So the server boots and can run based on the network config provided in the command line (a single IP address assigned by bootloader to whichever interface is plugged in). However, after cloud-init finshes, the server needs to run containers / VMs and I need to assign more than one IP address to it, and the ethernet devices need to use bonding. I suppose I could use move this functionality to ansible, which is what I use after cloud-init finishes, but then the network configuration is split across two different structures and I'd like to avoid that.

I understand this is a fringe case. If addressing this would be too much work, maybe update documentation to explain that in situations like this, you can work around the limitations by putting the netplan yaml into write_files and then use netplan apply in runcmd, so that other people will have it easier than me.