nplan with networkd + resolvconf without resolved, results in no DNS resolution

[Dimitri John Ledkov]

if nplan yaml specifies nameservers which are passed onto networkd, they will never take effect on systems that do not use systemd-resolved.

This is because there is no integration between nplan and resolvconf, either directly; via networkd; via NetworkManager.

[Dimitri John Ledkov (xnox)]

I guess that a .path unit can be setup to parse the private /run/systemd/netif/state file (or similar), which would then kick off and feed the DNS entries to resolfconf.

[Dimitri John Ledkov (xnox)]

<rharper> slangasek: xnox: re DNS for netplan/networkd ; on xenial , there is a unit watch placed on /run/systemd/netif/state which will trigger a call to systemd-network-resolvconf-update.service, which exec's some shell code to extract any DNS values from networkd state and the respective interfaces and invokes resolvconf program ;
<xnox> rharper, hm, that's what i was thinking should be happening.... I did not notice such watch. Where is it exactly, and does one have to activate it manually?
* xnox commented to the same effect on the bug i filed, that it seemed to me that networkd <-> resolvconf integration was non existant.
<rharper> you do not have to activate it manually; /lib/systemd/system/resovlconf.service.wants/systemd-networkd-resolvconf-update.path is the trigger for /lib/systemd/system/systemd-networkd-resolconf-update.service
<xnox> ./resolvconf.service.wants/systemd-networkd-resolvconf-update.path
<rharper> xnox: you probably want to add a symlink to /lib/systemd/system/systemd-networkd-wait-online.service in /etc/systemd/system/network-online.target.wants
<rharper> which bug?
<xnox> https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1689410
<mup> Bug #1689410: nplan with networkd + resolvconf without resolved, results in no DNS resolution <xenial> <ifupdown (Ubuntu):New> <nplan (Ubuntu):New> <resolvconf (Ubuntu):New> <systemd (Ubuntu):New> <https://launchpad.net/bugs/1689410>
<xnox> 30 seconds is a long time to get DNS settings right
<xnox> for some reason, my /run/systemd/netif/state had DNS, yet i did not have namespace resolution =(
<xnox> but i may have stopped resolvconf =(
<xnox> and hence ConditionPathExists=/run/resolvconf/enable-updates was not satisfied.
<xnox> thus a bug in my image.
<rharper> I can look at the bug, but it doesn't take 30 seconds when things are configured properly or things like network via cloud-init early would fail to resolve the snappy store, etc;
<xnox> yeah, things did fail to resolve snappy store, ubuntu ntp, etc.
<xnox> the bug is not very descriptive.
<rharper> right, I think if you add the systemd-networkd-wait-online link to the network-online.target.wants
<rharper> that should ensure it runs at the right time.
<xnox> nplan does that out of the box.
<rharper> only if 1) you have yaml in /etc/netplan/
<rharper> cloud-init invokes netplan generate
<xnox> but on first boot we are doing it half way during the boot (as cloud-init is running) thus it may not be part of the initial transaction.
<rharper> but since that's not called by a systemd-generator, it does not add the link
<xnox> .... cloud-init generates yaml into /etc/netplan.
<xnox> (when i force network generator to netplan, as I have in my xenial image, when experimenting to use nplan by default for this cloud)
<rharper> it does create the yaml and call generate, but it's not sufficient to create the symlink IIRC due to the code in netplan which doesn't generate the symlinks in /run if it;s not invoked as a genartor
<xnox> (via cloud.cfg.d)
<xnox> ah, fun.
<rharper> no
<rharper> this was not fun in any sense of the words
<rharper> I've picked this apart too many times; we've got the set of changes needed document...

[Steve Langasek (vorlon)]

Hi Ryan,

On Tue, May 09, 2017 at 02:20:17PM -0000, Dimitri John Ledkov wrote:

> <rharper> it does create the yaml and call generate, but it's not
> sufficient to create the symlink IIRC due to the code in netplan which
> doesn't generate the symlinks in /run if it;s not invoked as a genartor

There is no bug report at https://bugs.launchpad.net/ubuntu/+source/nplan
for this. Is there one on cloud-init?

> <rharper> I've picked this apart too many times; we've got the set of
> changes needed documented and staged for ubuntu-core

Where are these staged?

> <rharper> but it's not landed in xenial for cloud-init proper due to not
> wanting to foist networkd onto xenial users at this time

I don't understand this. Why would any of these staged changes not be
conditional on use of nplan, thus avoiding any "foisting"?

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

[Ryan Harper (raharper)]

On Tue, May 9, 2017 at 11:23 AM, Steve Langasek <
<email address hidden>> wrote:

> Hi Ryan,
>
> On Tue, May 09, 2017 at 02:20:17PM -0000, Dimitri John Ledkov wrote:
>
> > <rharper> it does create the yaml and call generate, but it's not
> > sufficient to create the symlink IIRC due to the code in netplan which
> > doesn't generate the symlinks in /run if it;s not invoked as a genartor
>
> There is no bug report at https://bugs.launchpad.net/ubuntu/+source/nplan
> for this. Is there one on cloud-init?
>

I did not file a bug against netplan for that; it's not clear to me that
it's a
bug in netplan, but I can and we can discuss the "late" cloud-init call to
netplan generate for the netplan rendere.

>
> > <rharper> I've picked this apart too many times; we've got the set of
> > changes needed documented and staged for ubuntu-core
>
> Where are these staged?
>

https://github.com/snapcore/core/pull/30
https://github.com/snapcore/core-build/pull/5
https://github.com/raharper/snapd/commit/3e83b3aa281f02bce9a230a812ad4f02d0d66c22

>
> > <rharper> but it's not landed in xenial for cloud-init proper due to not
> > wanting to foist networkd onto xenial users at this time
>
> I don't understand this. Why would any of these staged changes not be
> conditional on use of nplan, thus avoiding any "foisting"?
>

Maybe we can; I don't think we can change the default network renderer
in Xenial by default, that has upgrade implications; I don't think we want
to
switch existing users over to netplan by an upgrade to cloud-init.

I'm hesitant to say apt-get install nplan implies that you want cloud-init
to
use netplan to rendering things as well.

So what remains is some unit changes (ensure that network-online.target
depends on systemd-networkd-wait-online.service)
and cloud-config change (cloud-init's network renderer should be netplan
over eni).

How would those changes get introduced when a user wants to try netplan on
xenial?

>
> --
> Steve Langasek Give me a lever long enough and a Free OS
> Debian Developer to set it on, and I can move the world.
> Ubuntu Developer http://www.debian.org/
> <email address hidden> <email address hidden>
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1689410
>
> Title:
> nplan with networkd + resolvconf without resolved, results in no DNS
> resolution
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1689
> 410/+subscriptions
>

[Dimitri John Ledkov (xnox)]

On 9 May 2017 at 19:05, Ryan Harper <email address hidden> wrote:
> On Tue, May 9, 2017 at 11:23 AM, Steve Langasek <
> <email address hidden>> wrote:
>
> I'm hesitant to say apt-get install nplan implies that you want cloud-init
> to
> use netplan to rendering things as well.
>
> So what remains is some unit changes (ensure that network-online.target
> depends on systemd-networkd-wait-online.service)
> and cloud-config change (cloud-init's network renderer should be netplan
> over eni).
>
> How would those changes get introduced when a user wants to try netplan on
> xenial?
>

My understanding was that cloud-init does not re-initialise the
network for initialized instances, and thus an upgrade to cloud-init
and/or installation of nplan will not switch one's existing instance
to use nplan.
The understanding I had was the idea is to have newly provisioned
xenial instances to be nplan managed.

--
Regards,

Dimitri.

[Dimitri John Ledkov (xnox)]

Works as expected... when one actually has working networking /o\

case closed.