dns-* e/n/i are misplaced

[Ryan Beisner]

Given the following resultant e/n/i file, with indentation preserved, it appears that dns-* is intended as some sort of global setting. In fact, indentation is for convenience only, and those last dns-* entries are effectively applied to the iface immediate above it (eth3) in this case.

This may or may not cause functional issues, but it may be worth a re-consideration.

In this case, only eth0 is enabled.

# [A] No Juju: /etc/network/interfaces
# - Machine deployed via MAAS UI.
#
auto eth0
iface eth0 inet static
    dns-nameservers 10.245.168.2
    gateway 10.245.168.1
    address 10.245.168.11/21
    mtu 1500

auto eth1
iface eth1 inet manual
    mtu 1500

auto eth2
iface eth2 inet manual
    mtu 1500

auto eth3
iface eth3 inet manual
    mtu 1500

dns-nameservers 10.245.168.2
dns-search dellstack

[Ryan Beisner (1chb1n)]

ie. The original:

auto eth3
iface eth3 inet manual
    mtu 1500

dns-nameservers 10.245.168.2
dns-search dellstack

...is the same as...

auto eth3
iface eth3 inet manual
    mtu 1500
    dns-nameservers 10.245.168.2
    dns-search dellstack

...and the same as...

auto eth3
iface eth3 inet manual
mtu 1500
dns-nameservers 10.245.168.2
dns-search dellstack

[Andres Rodriguez (andreserl)]

Ryan, can yoyu please get this for us.

maas my-user node get_curtin_config <system_id>

[Andrew McDermott (frobware)]

I think we need to understand why it appears (and I say appears based on the way the file is rendered) that the dns-* options we see from a MAAS deployed node appear to be 'global', and not per NIC.

[Blake Rouse (blake-rouse)]

The get_curtin_config for that node will show that we pass that information to curtin as a global parameter that curtin provides. If that is incorrect for placing it in e/n/i then curtin should do the leg work and place it in resolvconf itself. Curtin provides the global option and MAAS uses it. Is a global option always invalid? Should a global option never be used? If that is the case then curtin should not have a global option as well.

[Ryan Beisner (1chb1n)]

Please consider using your MAAS dev lab to collect the necessary info, as the behavior is entirely predictable and consistent. I believe this to be reproducible on any MAAS 1.9 with any hardware, VM or otherwise.

I've got just 1 MAAS lab, it's for CI automation, and we really need to clear our test backlog now that we're back up and running from the Juju-proposed end. Thank you.

[Scott Moser (smoser)]

This bug is believed to be fixed in curtin in 17.1. If this is still a problem for you, please make a comment and set the state back to New

Thank you.