Comment 8 for bug 1843634

Based on the content in the description of the bug (the
previously-existing /etc/resolv.conf), cloud-init should *never* be
writing that file when 'netconf' is involved. It seems rather that
resolv.conf is generated based on contents of
/etc/sysconfig/network/config .

Maybe in the case that there was no dns information, cloud-init should nto
write /etc/sysconfig/network/config . It is not obvious to me that there
is a clean solution here, but if we take the policy in cloud-init of "do
not ever render empty dns settings", then that means a system that had old
dns settings but got no dns settings on this new instance id will continue
on with the old settings. DHCP muddies those waters for sure. Static
networking with explicitly empty dns settings probably is an edge case.

With regard to having to bring up the interface manually:
> I had to bring it up by executing "ifup eth0" from Azure.py code after
> the network config is applied. This way I was able to ssh into the VM.

I think that Ryan identified some incorrect ordering with cloud-init and
wicked that nees to be fixed.