This adds generic goroutine runner which simply wraps service as process
goroutine. It supports log redirection and basic panic handling.
DHCP-related part of the network package was slightly adjusted to run as
service with logging updates (to redirect logs to a file) and context
canceling.
Signed-off-by: Andrey Smirnov <smirnov.andrey@gmail.com>
* refactor(init): Allow kubeadm init on controlplane
This shifts the cluster formation from init(bootstrap) and join(control plane)
to init(control plane).
This makes use of the previously implemented initToken to provide a TTL for
cluster initialization to take place and allows us to mostly treat all control
plane nodes equal. This also sets up the path for us to handle master upgrades
and not be concerned with odd behavior when upgrading the previously defined
init node.
To facilitate kubeadm init across all control plane nodes, we make use of the
initToken to run `kubeadm init phase certs` command to generate any missing
certificates once. All other control plane nodes will attempt to sync the
necessary certs/files via all defined trustd endpoints and being the startup
process.
* feat(init): Add service runner context to PreFunc
Signed-off-by: Brad Beam <brad.beam@talos-systems.com>
This PR introduces dependencies between the services. Now each service
has two virtual events associated with it: 'up' (running and healthy)
and 'down' (finished or failed). These events are used to establish
correct order via conditions abstraction.
Service image unpacking was moved into 'pre' stage simplifying
`init/main.go`, service images are now closer to the code which runs the
service itself.
Step 'pre' now runs after 'wait' step, and service dependencies are now
mixed into other conditions of 'wait' step on startup.
Signed-off-by: Andrey Smirnov <smirnov.andrey@gmail.com>
Conditions are now implemented as interface with two methods: `Wait` for
condition to be true (cancelable via context) and 'String' which
describes what condition is waiting for.
Generic 'WaitForAll' was implemented to wait for multiple conditions at
once.
Signed-off-by: Andrey Smirnov <smirnov.andrey@gmail.com>
This started as a simple unit-test for file chunker, but the first test
hung immediately, so I started looking into the code.
One problem was that when entering inotify() code, ctx cancel wasn't
considered. Another problem is that remove fsnotify was never triggered,
but I saw that with unit-test later.
Small nit was that inotify() was initialized every time we got to EOF,
which is not efficient for "follow" mode.
So I moved inotify into the main loop, and plugged context cancel watch
into the place when chunk is delivered. Chunker code is supposed to
block in two places: when it tries to deliver next chunk (as client
might be slow to recieve buffers) or when there's no new data (on
inotify). So it makes sense to assert context canceled condition in both
cases.
Signed-off-by: Andrey Smirnov <smirnov.andrey@gmail.com>
This returns list of all the services registered, with their current
status, past events, health state, etc.
New CLI is `osctl service [<id>]`: without `<id>` it prints list of all
the services, with specific `<id>` it provides details for a service.
I decided to create "parallel" data structures in protobuf as Go
structures don't map nicely onto what protoc generates: pointers vs.
values, additional fields like mutexes, etc. Probably there's a better
approach, I'm open for it.
For CLI, I tried to keep CLI stuff in `cmd/` package, and I also created
simple wrapper to remove duplicated code which sets up client for each
command.
Examples:
```
$ osctl service
SERVICE STATE HEALTH LAST CHANGE LAST EVENT
containerd Running OK 21s ago Health check successful
kubeadm Running ? 2s ago Started task kubeadm (PID 280) for container kubeadm
kubelet Running ? 0s ago Started task kubelet (PID 383) for container kubelet
ntpd Running ? 14s ago Started task ntpd (PID 129) for container ntpd
osd Running ? 14s ago Started task osd (PID 126) for container osd
proxyd Waiting ? 14s ago Waiting for conditions
trustd Running ? 14s ago Started task trustd (PID 125) for container trustd
udevd Running ? 14s ago Started task udevd (PID 130) for container udevd
```
```
$ osctl service proxyd
ID proxyd
STATE Running
HEALTH ?
EVENTS [Preparing]: Running pre state (22s ago)
[Waiting]: Waiting for conditions (22s ago)
[Preparing]: Creating service runner (6s ago)
[Running]: Started task proxyd (PID 461) for container proxyd (6s ago)
```
Signed-off-by: Andrey Smirnov <smirnov.andrey@gmail.com>
As containerd client API wasn't closed after use, connection was leaking
every time healthcheck was run.
Signed-off-by: Andrey Smirnov <smirnov.andrey@gmail.com>
Without this we never set the namespace for the context which prevents it from functioning at all
Signed-off-by: Brad Beam <brad.beam@talos-systems.com>
WithParentCgroupDevices uses the default cgroup setup to inherit the container's parent cgroup's allowed and denied devices
Without this, we get 'operation not permitted' when attempting to read the block devices.
Signed-off-by: Andrew Rynhard <andrew@andrewrynhard.com>
We should still support username and password for backwards compatibility.
This also sets us up for for implementing auth for users using something like LDAP in the future.
Signed-off-by: Andrew Rynhard <andrew@andrewrynhard.com>
This implements insecure over-file-socket gRPC API for init with two
first simplest APIs: reboot and shutdown (poweroff).
File socket is mounted only to `osd` service, so it is the only service
which can access init API. Osd forwards reboot/shutdown already
implemented APIs to init which actually executes these.
This enables graceful shutdown/reboot with service shutdown, sync, etc.
Signed-off-by: Andrey Smirnov <smirnov.andrey@gmail.com>
Most crucial changes in `init/main.go`: on shutdown now Talos tries
to stop gracefully all the services. All the shutdown paths are unified,
including poweroff, reboot and panic handling on startup.
While I was at it, I also fixed bug with containers failing to start
when old snapshot is still around.
Service lifecycle is wrapped with `ServiceRunner` object now which
handles state transitions and captures events related to state changes.
Every change goes to the log as well.
There's no way to capture service state yet, but that is planned to be
implemented as RPC API for `init` which is exposed via `osd` to `osctl`.
Future steps:
1. Implement service dependencies for correct startup order and
shutdown order.
2. Implement service health, so that we can say "start trustd when
containerd is up and healthy".
3. Implement gRPC API for init, expose via osd (service status, restart,
poweroff, ...)
4. Impement 'String()' for conditions, so that we can see what service
is waiting on right now.
Signed-off-by: Andrey Smirnov <smirnov.andrey@gmail.com>
This changes `runner.Runner` API to support more methods to allow for
containerd runner to create container object only once, and start/stop
tasks to implement restarts.
New API: `Open()` (initialize), `Run()` (run once until exits), `Stop()`
(stop running instance), `Close()` (free resource, no longer available
for new `Run()`).
So the sequence might be: `Open`, `Run`, `Stop`, `Run`, `Stop`, `Close`.
Process and containerd runners were updated for the new API, and
'restart' part was removed, now both runners only run the task once.
Restart piece was implemented in an abstract way for any wrapped
`runner.Runner` in the `runner/restart` package. Restart supports three
restart policies: `Once`, `UntilSuccess` and `Forever`.
Service API was changed slightly to return the `runner.Runner`
interface, and `system.Services` now handles running the service.
For all the services, code was adjusted to either return runner (run
once), or was wrapped with `restart` runner to provide restart policy.
Signed-off-by: Andrey Smirnov <smirnov.andrey@gmail.com>
Just because we can easily do that, this also covers prior work
on converting panics to errors: #518
Signed-off-by: Andrey Smirnov <smirnov.andrey@gmail.com>
