This is next part of networkd rewrite.
This implements three new resource types coupled with controllers which
process the default configuration, merges and applying changes.
TimeSync was set up to watch the time servers resource. This is a no-op
for now, but once DHCP is implemented, this would enable time server
configuration coming from DHCP.
Signed-off-by: Andrey Smirnov <smirnov.andrey@gmail.com>
This controller provides three important aggregated resources to be
consumed by different interested parties:
* "default" node IP
* "current" addresses (node can be reached on these at the moment)
* "accumulative" addresses (for certSANs)
Example:
```
$ talosctl get nodeaddresses -n 172.20.0.2
NODE NAMESPACE TYPE ID VERSION ADDRESSES
172.20.0.2 network NodeAddress accumulative 4 ["10.244.0.0","10.244.0.1","172.20.0.2"]
172.20.0.2 network NodeAddress current 6 ["10.244.0.0","10.244.0.1","172.20.0.2"]
172.20.0.2 network NodeAddress default 1 ["172.20.0.2"]
```
Signed-off-by: Andrey Smirnov <smirnov.andrey@gmail.com>
It was a bad choice to name the method which returns resource spec
typecasted to the proper Go type as `Status()`, as certainly `Status`
has a different meaning for resources. So rename the method accordingly
to be `TypedSpec()`.
No functional or user-visbile changes, just renames.
Signed-off-by: Andrey Smirnov <smirnov.andrey@gmail.com>
The structure of the controllers is really similar to addresses and
routes:
* `LinkSpec` resource describes desired link state
* `LinkConfig` controller generates `LinkSpecs` based on machine
configuration and kernel cmdline
* `LinkMerge` controller merges multiple configuration sources into a
single `LinkSpec` paying attention to the config layer priority
* `LinkSpec` controller applies the specs to the kernel state
Controller `LinkStatus` (which was implemented before) watches the
kernel state and publishes current link status.
Signed-off-by: Andrey Smirnov <smirnov.andrey@gmail.com>
This controller queries addresses of all the interfaces in the system
and presents them as resources. The idea is that can be a source for
many decisions - e.g. whether network is ready (physical interface has
scope global address assigned).
This is also good for debugging purposes.
Examples:
```
$ talosctl -n 172.20.0.2 get addresses
NODE NAMESPACE TYPE ID VERSION
172.20.0.2 network AddressStatus cni0/10.244.0.1/24 1
172.20.0.2 network AddressStatus cni0/fe80::9c87:cdff:fe8e:5fdc/64 2
172.20.0.2 network AddressStatus eth0/172.20.0.2/24 1
172.20.0.2 network AddressStatus eth0/fe80::ac1b:9cff:fe19:6b47/64 2
172.20.0.2 network AddressStatus flannel.1/10.244.0.0/32 1
172.20.0.2 network AddressStatus flannel.1/fe80::440b:67ff:fe99:c18f/64 2
172.20.0.2 network AddressStatus lo/127.0.0.1/8 1
172.20.0.2 network AddressStatus lo/::1/128 1
172.20.0.2 network AddressStatus veth178e9b31/fe80::6040:1dff:fe5b:ae1a/64 2
172.20.0.2 network AddressStatus vethb0b96a94/fe80::2473:86ff:fece:1954/64 2
```
```
$ talosctl -n 172.20.0.2 get addresses -o yaml eth0/172.20.0.2/24
node: 172.20.0.2
metadata:
namespace: network
type: AddressStatuses.net.talos.dev
id: eth0/172.20.0.2/24
version: 1
owner: network.AddressStatusController
phase: running
spec:
address: 172.20.0.2/24
local: 172.20.0.2
broadcast: 172.20.0.255
linkIndex: 4
linkName: eth0
family: inet4
scope: global
flags: permanent
```
Signed-off-by: Andrey Smirnov <smirnov.andrey@gmail.com>
