Comment 18 for bug 1750884

Whether or not /e/n/i supports something correctly or just happens to work by sheer luck has no bearing on what is technically correct and sensical -- let's abstract this, what we need to concern ourselves with here is netplan, cloud-init and maas.

In the network world, it is absolutely true that DNS nameservers only make sense on a per-interface basis: nothing guarantees that a "globally-set" nameserver of 8.8.8.8 is reachable through all interfaces. It just happens to be that way on 99% of systems because they only connect to one network, through one interface.

So, in light of the nameserver setting in MaaS under Settings being unspecified, there's /no other way/ but to either set the nameserver globally or try to guess the right interface (either by which is connected to MaaS, or which gets the default gateway, or which matches subnets). None of the detection options I could come up with strike me as particularly solid and foolproof.

Next steps for netplan strike me as being to add support for global nameservers even if it's silly; we shouldn't expect users to have to have the level of knowledge of networking to know to set it up on a particular interface when it will work correctly as "global" for 99% of cases.

In MaaS, my opinion is that every effort should be taken to allow network administrators to set things up correctly -- nothing guarantees that the systems deployed will remain accessible to MaaS, or that it will be their main interface to the network. Only allowing global DNS is brittle at best, and breaks at least what *I* have been taught were best practices, to have a separate "public" network from the authenticated "private" side where monitoring and/or deployment happens. Maybe I'm just the one who's particular in doing this.

I'm not sure what next steps are for cloud-init -- given a valid configuration, I assumed it should just pass it through to netplan if it's v2.

I'll take care of the "global DNS" implementation in netplan.