Netplan

Bug #1664844
Comment #6

Comment 6 for bug 1664844

Revision history for this message

Ryan Harper (raharper) wrote on 2017-02-15: Re: [Bug 1664844] Re: No distinction between link-up and link-down interfaces

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.

>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1664844
>
> Title:
> No distinction between link-up and link-down interfaces
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/netplan/+bug/1664844/+subscriptions
>

On Wed, Feb 15, 2017 at 12:51 PM, Mike Pontillo <mike.pontillo@canonical.com
> wrote:

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.
>

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.

>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1664844
>
> Title:
>   No distinction between link-up and link-down interfaces
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/netplan/+bug/1664844/+subscriptions
>