On Wed, Feb 15, 2017 at 12:51 PM, Mike Pontillo <<email address hidden>
> wrote:
> I respectfully disagree. Think of deploying a simple router, such as a
> home NAT gateway. You would likely want wan0 to be in a mode like I
> described, "link-up interface with DHCP enabled, but don't block boot if
> you can't DHCP".
>
I certainly agree that there's a need for dynamic configuration of
interfaces.
Networkd doesn't currently provide a complete solution here. And it
certainly
does not provide any link-state monitoring either; but we didn't have one
in
ifupdown either; collection of additional hooks/scripts/tools providing
this function not-with-standing.
I don't think it's clear that not blocking or blocking is the right or
expected
behavior; it's certainly possible that not getting an IP via DHCP might be
equivalent to not booting if that's the only ingress to the box remotely.
> - If I can't get a DHCP address, that's a problem, but I still don't
> want to block the boot process. Hopefully my ISP's problem. But I don't
> want it to block boot. I want the normal DHCP client behavior of
> exponential-backoff-and-retry until it works. I want the router to be up
> and running, and properly sending "destination host unreachable" ICMP
> messages back to clients, not stuck waiting for systemd to confirm what
> I already know.
>
There's clearly a need for this feature, but I don't believe we want to
replicate
a collection of hooks/scripts to deliver this but rather examine what might
be
needed to deliver netlink monitoring/policy application as a first-class
feature.
I briefly looked at https://en.opensuse.org/Portal:Wicked which has a nanny
daemon listening to netlink and the network daemon to handle hotplug events
but can be extended to listen to link status and build actions based on
information.
On Wed, Feb 15, 2017 at 12:51 PM, Mike Pontillo <<email address hidden>
> wrote:
> I respectfully disagree. Think of deploying a simple router, such as a
> home NAT gateway. You would likely want wan0 to be in a mode like I
> described, "link-up interface with DHCP enabled, but don't block boot if
> you can't DHCP".
>
I certainly agree that there's a need for dynamic configuration of
interfaces.
Networkd doesn't currently provide a complete solution here. And it
certainly
does not provide any link-state monitoring either; but we didn't have one
in
ifupdown either; collection of additional hooks/scripts/tools providing
this function not-with-standing.
I don't think it's clear that not blocking or blocking is the right or
expected
behavior; it's certainly possible that not getting an IP via DHCP might be
equivalent to not booting if that's the only ingress to the box remotely.
> - If I can't get a DHCP address, that's a problem, but I still don't backoff- and-retry until it works. I want the router to be up
> want to block the boot process. Hopefully my ISP's problem. But I don't
> want it to block boot. I want the normal DHCP client behavior of
> exponential-
> and running, and properly sending "destination host unreachable" ICMP
> messages back to clients, not stuck waiting for systemd to confirm what
> I already know.
>
There's clearly a need for this feature, but I don't believe we want to
replicate
a collection of hooks/scripts to deliver this but rather examine what might
be
needed to deliver netlink monitoring/policy application as a first-class
feature.
I briefly looked at https:/ /en.opensuse. org/Portal: Wicked which has a nanny
daemon listening to netlink and the network daemon to handle hotplug events
but can be extended to listen to link status and build actions based on
information.
> /bugs.launchpad .net/bugs/ 1664844 /bugs.launchpad .net/netplan/ +bug/1664844/ +subscriptions
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https:/
>
> Title:
> No distinction between link-up and link-down interfaces
>
> To manage notifications about this bug go to:
> https:/
>