Configure all interfaces where DHCP answers

[aplanas]

• Configure all interfaces where DHCP answer

• Fix grep stderr output in is_raspberry that happens in non-rpi devices

[aplanas]

Note that is on top of the other branch. I will rebase accordingly if the other branch gets merged.

[Vogtinator]

Question is whether the pre-MULTINET behaviour was actually useful.

IMO we can just use this by default, I don't see any downside in enabling DHCP for all interfaces. Which interface is first is also not really guaranteed anyway.

@gmoro: Any reason this was done this IMO overcomplicated way? I'd rather just enable DHCP for all interfaces which get an IP.

[aplanas]

@Vogtinator I agree with your comment. I would drop this logic of IPADDRESS vs GATEWAYS, but maybe there were a reason for that.

[Vogtinator]

@aplanas: I'd say: Go for it. Then we also don't need a config option.

[aplanas]

@Vogtinator done.

[Vogtinator]

IMO GATEWAYS should also be ignored. Getting an IP address is good enough for DHCP activation.

[aplanas]

IMO GATEWAYS should also be ignored. Getting an IP address is good enough for DHCP activation.

I agree. I will change that according to @gmoro comments.

[gmoro]

Question is whether the pre-MULTINET behaviour was actually useful.

IMO we can just use this by default, I don't see any downside in enabling DHCP for all interfaces. Which interface is first is also not really guaranteed anyway.

@gmoro: Any reason this was done this IMO overcomplicated way? I'd rather just enable DHCP for all interfaces which get an IP.

This part was actually coded by the maintainer of wicked, and the idea was to use the first configurable network, of course we can rethink it, if we have multiple nets which one are we going to use for the default route? What exactly would be the use case for multiple networks to be configured in the firstboot?

[Vogtinator]

This part was actually coded by the maintainer of wicked, and the idea was to use the first configurable network, of course we can rethink it, if we have multiple nets which one are we going to use for the default route?

Neither of those options are perfect, but potentially having conflicting options for a default route (which shouldn't happen in a well defined environment) might be better than having to set up DHCP for other interfaces manually in case the selection was wrong.

That depends on wicked's behaviour for the conflict situation though, do you have any more info about that?

[aplanas]

@gmoro: Any reason this was done this IMO overcomplicated way? I'd rather just enable DHCP for all interfaces which get an IP.

This part was actually coded by the maintainer of wicked, and the idea was to use the first configurable network, of course we can rethink it, if we have multiple nets which one are we going to use for the default route?

Uhm, I wonder if this is not task for the DHCP administrator to decide, and not for firstboot.

What exactly would be the use case for multiple networks to be configured in the firstboot?

The use case is simple: derivatives from JeOS can be used in scenarios were multiple interfaces are available. In cloud and kubernetes cloud-init or ignition will configure the interfaces, but in other environments firstboot will need to assign some same defaults.

[Vogtinator]

LGTM, just needs to be rebased on master after the other PR gets merged

[aplanas]

Rebased on top of the other PR (that is now also rebased from the new master)

[gmoro]

That depends on wicked's behaviour for the conflict situation though, do you have any more info about that?

I don't, but let's go with it as it is.

[gmoro]

LGTM

[Vogtinator]

Don't merge before #49 got merged and this PR rebased on top.