We keep running into:
https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1563296
https://bugs.launchpad.net/curtin/+bug/1586075
https://bugs.launchpad.net/maas/+bug/1588706
https://bugs.launchpad.net/curtin/+bug/1582410
and it affects customers too:
https://bugs.launchpad.net/juju-core/+bug/1603473
There is the advertised curtin workaround to remove both eth0.cfg and 50-cloud-init.cfg as the MAAS image is being deployed through a custom preseed - and this has worked and been sufficient to date.
However, the fixes in curtin have not moved from 'fix committed' and as such we continue to experience this issue. I propose that we change the bridge script to drop all 'source' stanzas so that we don't run into this problem anymore.
We had initially decided to use the workaround and leave the 'source' stanzas in place as that is the extension mechanism. I don't think we should we wait any longer as this is still hitting deployments of precise, trusty and xenial.
From a charmers perspective they can always add back the 'source' stanza if they find it missing during charm deployment. Our removal of the source stanza is a one-time affair.
From juju's perspective we should own the initial network configuration of the machine during the initial boot. If we drop the source stanzas our bridge procedure becomes:
$ ifdown -a
$ <rewrite-etc-network-interfaces-to-be-bridged>
$ ifup -a
In this scenario we would take down all interfaces, including those originally source'd from /etc/network/interfaces.d/*.cfg and only bring up those interfaces in the newly created ENI which would no longer have the source stanza.
There are workarounds listed for this bug here:
https:/ /bugs.launchpad .net/maas/ +bug/1590689