Comment 4 for bug 1636912

@Steve:

> There's feedback in the end of that bug that cloud-init should *not* be using Before=basic.target / Before=dbus.socket, but instead use Before=sysinit.target.

Correct, that would avoid starting it in between sysinit.target and basic.target when the sockets start, and avoid the deadlock in a simpler way.

> I thought that once resolved supported DNS, we would use that /instead of/ the NSS module. Is there really a benefit to using both?

Both "resolve" and "dns" are NSS modules, and you can't not use NSS for name resolution (as that's what glibc's gethostbyname() and friends use). Maybe you meant "instead of the dns module"? This is a required fallback for either (1) foreign architecture programs which don't have the corresponding nss-resolve:arch installed, or (2) early boot when D-Bus and hence resolved are not yet running.

> because Ubuntu Core 16 does contain libnss-resolve,

"contains" yes, but we don't use nss-resolve in Ubuntu 16.04 and hence snappy. This got introduced step-wise in 16.10, isn't completly finished yet, and IMHO not yet ready for backporting (if we ever actually want that). If snappy's /etc/nsswitch.conf contains "resolve", this is NOT intended.

@Ryan:

> I don't know enough to say if resolved and NSS are 100% swappable;

Again, I figure you mean s/NSS/dns/; dns does not do DNSSEC, caching and the like, but none of this should be relevant at early boot (if you need network that early, you are basically on your own and not guaranteed to succeed anyway -- "dns" is by far good enough for that).

Anyway, all of this is not the primary focus for this bug -- this bug is about the ordering of cloud-init vs. networkd, resolved is not in this picture.