use default broadcast source address for add-node hint

[nihr43]

Summary

This simplifies the address detection a bit for the 'add-node' command hint, enabling a use case where FRR or similar is installing the default route via multiple 'unnumbered' interfaces:

# microk8s add-node
From the node you wish to join to this cluster, run the following:
microk8s join none:25000/........

# ip route show default
default nhid 151 proto bgp metric 20 
	nexthop via inet6 fe80::290:bff:fea5:e2d3 dev bgpenp36s0 weight 1 
	nexthop via inet6 fe80::290:bff:fea5:deab dev bgpenp35s0 weight 1 

# ip route get 255.255.255.255
broadcast 255.255.255.255 dev bgpenp35s0 src 10.0.200.1 uid 0 
    cache <local,brd> 

Changes

Instead of fetching the default route interface and then its address, the suggested change simply finds the system-wide default source address for 255.255.255.255. In a typical dhcp or static ip scenario, this will be the expected interface; in my 'L3 to the hypervisor' scenario, this will be a loopback /32 ipv4 address.

Testing

I've tested this by simply running snapcraft build and installing the artifact. First on a machine running bgp, with 10.0.200.255/32 on lo:

$ snapcraft build
$ sudo snap install microk8s_v1.28.2_amd64.snap --dangerous --classic
$ microk8s add-node
From the node you wish to join to this cluster, run the following:
microk8s join 10.0.200.255:25000/e6f7f77b060d7b53bba6c97db29bfc47/aab0f29f6056

Then on an lxd vm with basic networking:

$ lxc file push microk8s_v1.28.2_amd64.snap microk8s/root/
$ lxc shell microk8s
root@microk8s:~# snap install microk8s_v1.28.2_amd64.snap --dangerous --classic
root@microk8s:~# microk8s add-node
From the node you wish to join to this cluster, run the following:
microk8s join 10.11.228.100:25000/7bf37091dd4c3f0abad312f16beb23ee/e369d5eb414d

I need guidance on running the legitimate test suite, it seems the testing documentation is outdated.

Possible Regressions

Checklist

• [x ] Read the contributions page.
• [x ] Submitted the CLA form, if you are a first time contributor.
• The introduced changes are covered by unit and/or integration tests.

Notes

[neoaggelos]

Hi @nihr43, thanks for the PR, I see why this is useful.

However, I am afraid that this would break airgap environments where a route to 255.255.255.255 might not be available:

root@u3:~# ip r
10.0.0.0/16 dev eth0 proto kernel scope link src 10.0.0.41 
10.0.0.1 dev eth0 proto dhcp scope link src 10.0.0.41 metric 100 
root@u3:~# ip route get 255.255.255.255
RTNETLINK answers: Network is unreachable

However, I see the value in the change that you propose. Would you be willing to fallback to your method if the first does not find an IP?

e.g. something like

local IP_ADDR="$(as is)"
if [[ -z "$IP_ADDR" ]]; then
  local IP_ADDR="$($SNAP/sbin/ip route get 255.255.255.255 | $SNAP/usr/bin/gawk '{for(i=1; i<NF; i++) if($i=="src") print$(i+1)}' | head -1)"
fi

if [[ -z "$IP_ADDR" ]]; then
        echo "none"
fi

[nihr43]

yep that works.

about the CLA check that failed earlier; I think the check ran before my CLA submission was officially "accepted". I expect it to work the next time around.

[neoaggelos]

LGTM, thanks @nihr43!

[neoaggelos]

@nihr43 I rebased against latest master to get a CI run. After it's green, we're good to merge. Thanks again for the PR!