This controller based on machine configuration, cmdline, defaults,
produces configuration for the operators - what operators should run,
what are the parameters for the operators, etc.
Signed-off-by: Andrey Smirnov <smirnov.andrey@gmail.com>
This resource holds aggregated network status which can be easily used
in various places to wait for the network to reach some desired state.
The state checks are simple right now, we might improve the logic to
make sure all the configured network subsystems reached defined state,
but this might come later as we refine the logic (e.g. to make sure that
all static configuration got applied, etc.)
Signed-off-by: Andrey Smirnov <smirnov.andrey@gmail.com>
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>
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>
Route handling is very similar to addresses:
* `RouteStatus` describes kernel routing table state,
`RouteStatusController` reflects kernel state into resources
* `RouteSpec` defines routes to be configured
* `RouteConfigController` creates `RouteSpec`s based on cmdline and
machine configuration
* `RouteMergeController` merges different configuration layers into the
final representation
* `RouteSpecController` applies the specs to the kernel routing table
Signed-off-by: Andrey Smirnov <smirnov.andrey@gmail.com>
This includes multiple controllers responsible for different stages of
`AddressSpec` conversion:
* `AddressConfigController` produces initial unmerged configuration from
multiple sources (more sources coming later, e.g. DHCP)
* `AddressMergeController` merges address configuration into final
representation
* `AddressSpecController` syncs resources with kernel state
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>
This is the first PR of many which implement new COSI network
configuration. This controller provides low-level status of the network
interfaces (links) not touching on the addresses of the interface.
The information gathered resembles output of `ip link show` command.
Examples:
```
$ talosctl -n 172.20.0.2 get links
NODE NAMESPACE TYPE ID VERSION TYPE KIND HW ADDR OPER STATE LINK STATE
172.20.0.2 net LinkStatus bond0 1 ether bond fe:c4:d6:4c:04:05 down false
172.20.0.2 net LinkStatus cni0 5 ether bridge 22:cc:25:7e:64:19 up true
172.20.0.2 net LinkStatus dummy0 1 ether dummy 0e:f6:f3:ef:53:29 down false
172.20.0.2 net LinkStatus eth0 4 ether ae:1b:9c:19:6b:47 up true
172.20.0.2 net LinkStatus flannel.1 2 ether vxlan be:c5:4f:eb:da:5c unknown true
172.20.0.2 net LinkStatus ip6tnl0 1 tunnel6 ip6tnl 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00 down false
172.20.0.2 net LinkStatus lo 4 loopback 00:00:00:00:00:00 unknown true
172.20.0.2 net LinkStatus sit0 1 sit sit 00:00:00:00 down false
172.20.0.2 net LinkStatus teql0 1 void down false
172.20.0.2 net LinkStatus tunl0 1 ipip ipip 00:00:00:00 down false
172.20.0.2 net LinkStatus veth1c1422df 2 ether veth 6a:2d:68:be:8e:8f up true
172.20.0.2 net LinkStatus veth2ce7ce8d 1 ether veth 52:fc:98:82:f7:29 up true
```
```
$ talosctl -n 172.20.0.2 get links eth0 -o yaml
node: 172.20.0.2
metadata:
namespace: net
type: LinkStatuses.net.talos.dev
id: eth0
version: 4
owner: network.LinkStatusController
phase: running
spec:
index: 4
type: ether
linkIndex: 0
flags: UP,BROADCAST,RUNNING,MULTICAST,LOWER_UP
hardwareAddr: ae:1b:9c:19:6b:47
broadcastAddr: ff:ff:ff:ff:ff:ff
mtu: 1500
queueDisc: pfifo_fast
operationalState: up
kind: ""
slaveKind: ""
linkState: true
speedMbit: 4294967295
port: Other
duplex: Unknown
```
Signed-off-by: Andrey Smirnov <smirnov.andrey@gmail.com>
