When a machine is connected to SideroLink over the GRPC tunnel in maintenance mode, its tunnel config gets overwritten when a machine config is applied to it.
Instead, check the link to determine the tunnel setting and preserve it on allocation.
Since we are not explicit about this setting and not always leave it to the Omni-wide configuration, rework the Omni-wide configuration to
- allow opt-in if it is disabled instance-wide
- do not allow opt-out if it is enabled instance-wide
This allows us to preserve the current behavior of "forcing" the machines without explicit configuration to use the system default.
Signed-off-by: Utku Ozdemir <utku.ozdemir@siderolabs.com>
By default, generated Talos installation media uses `grpc_tunnel` for SideroLink based on the Omni instance configuration, namely via `--siderolink-use-grpc-tunnel` flag.
Allow overriding this setting in `omnictl download` and in Download Installation Media screen on the web.
On the Download Installation Media screen, the default value of the checkbox is based on the instance default.
Closessiderolabs/omni#388.
Signed-off-by: Utku Ozdemir <utku.ozdemir@siderolabs.com>
Correctly handle the retrieval and updates of schematics when a Talos node has secure boot enabled.
When secure boot is enabled, we now
- Use the correct installer image, `installer-secureboot` instead of `installer`
- Preserve the kernel args in the schematic on install/upgrade instead of stripping them away.
For non-secureboot, we keep everything as-is, to avoid triggering an upgrade of existing nodes.
Signed-off-by: Utku Ozdemir <utku.ozdemir@siderolabs.com>
Additionally add validation for the labels meta arguments in
the `CreateSchematic` API.
Implement integration test that use omnictl to download the images with labels added.
Signed-off-by: Artem Chernyshev <artem.chernyshev@talos-systems.com>
Fixes: https://github.com/siderolabs/omni/issues/143
This is crucial if we want to support SBCs in Omni.
Automatically detect which overlay we need to install when any SBC type
is selected on the backend.
Move some of filename generation to the backend, as it's now Talos
version dependent.
Signed-off-by: Artem Chernyshev <artem.chernyshev@talos-systems.com>
When determining the schematic ID of a machine, instead of relying the ID on the schematic ID meta-extension, compute the ID by gathering the extensions on the machine. This way, the extension ID will not contain the META values, labels or the kernel args.
This ID is actually the ID we need, as when we compare the desired schematic with the actual one during a Talos upgrade, we are only interested in the changes in the list of extensions.
This does not cause the kernel args, labels, etc. to disappear, as they are used at installation time and preserved afterward (e.g., during upgrades).
Additionally:
- Remove the list of extensions from the `Schematic` resource, as it relied upon the schematics always being created through Omni. This is not always the case - i.e., when a partial join config is used. Therefore, instead of relying on it, we store the list of extensions by directly reading them from the machine and storing them on the `MachineStatus` resource.
- Skip setting the schematic META section at all if there are no labels set on Download Installation Media screen.
Closessiderolabs/omni#55.
Signed-off-by: Utku Ozdemir <utku.ozdemir@siderolabs.com>
Omni is source-available under BUSL.
Signed-off-by: Andrey Smirnov <andrey.smirnov@siderolabs.com>
Co-Authored-By: Artem Chernyshev <artem.chernyshev@talos-systems.com>
Co-Authored-By: Utku Ozdemir <utku.ozdemir@siderolabs.com>
Co-Authored-By: Dmitriy Matrenichev <dmitry.matrenichev@siderolabs.com>
Co-Authored-By: Philipp Sauter <philipp.sauter@siderolabs.com>
Co-Authored-By: Noel Georgi <git@frezbo.dev>
Co-Authored-By: evgeniybryzh <evgeniybryzh@gmail.com>
Co-Authored-By: Tim Jones <tim.jones@siderolabs.com>
Co-Authored-By: Andrew Rynhard <andrew@rynhard.io>
Co-Authored-By: Spencer Smith <spencer.smith@talos-systems.com>
Co-Authored-By: Christian Rolland <christian.rolland@siderolabs.com>
Co-Authored-By: Gerard de Leeuw <gdeleeuw@leeuwit.nl>
Co-Authored-By: Steve Francis <67986293+steverfrancis@users.noreply.github.com>
Co-Authored-By: Volodymyr Mazurets <volodymyrmazureets@gmail.com>
