Comment 5 for bug 1582410

maas images for precise newer than 20160517 will have cloud-init from the ppa again.

Now, in reply to comment 3.

> So in precise, we have cloud-init 0.6.3-0ubuntu1.25, which does not appear to
> include the logic to remove this file (this is in newer cloud-init which
> supports writing out networking config).

Even then, when curtin disables cloud-init networking, it cloud-init's removal
of this file also.

> Oddly, the release image, includes cloud-init 0.7.0; which is newer but not
> new enough to support the network config which also will remove this legacy
> /etc/network/interfaces.d/eth0.cfg if supplied with a network config.

see
https://launchpad.net/~maas-maintainers/+archive/ubuntu/maas-ephemeral-images
for what and why, but basically precise released before maas and maas support
was somewhat bolted on via this archive.

> I suspect that the deployment with release; the network config used has the
> nic name set to eth0.

Or maas used a curtin < revision 382. Which would not write 'source *.cfg'
and would thus ignore the eth0.cfg that was in it. I can't come up with a
way that 2 identical deploys would otherwise behave differently on this.

> This can be fixed in a few ways; we can decide which one's best here.
>
> 1. The maas image for precise (release and daily) can skip inclusion of this
> file; this would be a change on the image build side. This would likely break
> older maas deployments where maas isn't modeling networking nor using a
> curtin new enough to generate the network config.
>
> 2. newer maas can inject a curthooks entry to remove
> /etc/network/interfaces.d/eth0.cfg if it exists and matches the known
> configuration
>
> Basically a terse version of cloud-init's _maybe_remove_legacy_eth0().
>
> 3. curtin can run this _maybe_remove_legacy_eth0() function if it knows it's
> writing a network configuration.
>
> I think _3_ is the best option; but it requires updating curtin. _2_ works
> without changing curtin, but then requires a maas update. _1_ I don't think
> is ideal here since it may break older maas installs.

I think 3 is the best option. Its safe to remove a file named eth0.cfg
that has known build-output content. That is what cloud-init does. If
the user intended to place an 'eth0.cfg' file and have it respected, they
have to any one of:
 a.) name it differently (local-eth0.cfg)
 b.) adding a trailing blank line.

cloud-init's _maybe_remove_legacy_eth0 will only remove the file if
its contents with lines starting with '#' removed is exactly:
 auto eth0
 iface eth0 inet dhcp

so just adding
 <space># asdf

its not the prettiest work around, but 'a' will allow effectively the same thing, and this is not an expected path.