IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Adds a timezone file for UTC to the rootfs and create a symlink for it
at /etc/localtime
Fixes#4840
Signed-off-by: Philipp Sauter <sauterp@protonmail.com>
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
See #4816
Depending on the hardware and firmware type, firmware might be either
needed during initial boot (`initramfs`) or in the Talos running phase
(`rootfs`). As we don't want to have two copies of same firmware, share
the firmware by bind-mounting it from the `initramfs` down to `rootfs`
on switchroot.
This also cleans up `Dockerfile` to keep firmware only in `initramfs`.
Eventually we might get rid of some of the firmware and move it to the
system extensions.
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
Fixes#4815
This implements the following steps:
* machine configuration updates
* pulling and unpacking system extension images
* validating, listing system extensions
* re-packing system extensions
* preserving installed extensions in `/etc/extensions.yaml`
Once extension is enabled, raw information can be queried with:
```
$ talosctl -n 172.20.0.2 cat /etc/extensions.yaml
layers:
- image: 000.ghcr.io-smira-gvisor-c927b54-dirty.sqsh
metadata:
name: gvisor
version: 20220117.0-v1.0.0
author: Andrew Rynhard
description: |
This system extension provides gVisor using containerd's runtime handler.
compatibility:
talos:
version: '> v0.15.0-alpha.1'
```
This was tested with the `gvisor` system extension.
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
Version was never passed properly, plus the goreleaser is deprecated
now, switch to golangci-lint equivalent script.
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
Containerd doesn't support merging plugin configuration from multiple
sources, and Talos has several pieces which configure CRI plugin:
(see https://github.com/containerd/containerd/issues/5837)
* base config
* registry mirror config
* system extensions
* ...
So we implement our own simple way of merging config parts (by simply
concatenating text files) to build a final `cri.toml`.
At the same time containerd migrated to a new format to specify registry
mirror configuration, while old way (via CRI config) is going to be
removed in 1.7.0. New way also allows to apply most of registry
configuration (except for auth) on the fly.
Also, containerd was updated to 1.6.0-rc.0 and runc to 1.1.0.
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
This will be required to preserve platform network configuration in a
cache across boots. Network configuration will be marshaled to YAML and
unmarshaled back.
Changes are pretty simple and most of the code is auto-generated:
replace `stringer` codegen with `enumer` which produces also methods
which convert from string back to enum values.
Added tests to verify YAML marshaling/unmarshaling.
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
Fixes#4759
This uses existing features: Talos always generates 32 bytes random node
identity, we use first 16 bytes of that to generate `machine-id` in
compliant format and mount that into the `kubelet` container.
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
Update Go modules to the latest versions including talos-systems/
released modules.
In preparation for 0.14-beta release.
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
The `installer` image is used for initial install and upgrades, so it
contains only Talos artifacts for the same arch as the image
The `imager` image is used to produce Talos images, so it contains artifacts
for all arhitectures, so that it's possible e.g. to build Raspberry PI
Talos image on amd64 machine
Unpacked size comparison for amd64 (before this change, size of
`installer` was same as `imager` size):
```
REPOSITORY TAG IMAGE ID CREATED SIZE
ghcr.io/smira/installer v0.14.0-alpha.2-8-g73293bc2-dirty 264995cf56df 4 minutes ago 176MB
ghcr.io/smira/imager v0.14.0-alpha.2-8-g73293bc2-dirty 3ba8e0176565 6 minutes ago 616MB
```
As the `installer` image is pulled into `tmpfs` on upgrade, it's important
to have it as small as possible to avoid putting too much pressure on
node memory.
Both images are generated anyways for both `amd64` and `arm64` target
architectures.
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
Still no proper tags for Kubernetes modules (known issue upstream).
Also bump dependencies.
Closes#4605closes#4606
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
Fixes#4279
These APIs were deprecated in 0.13, now it's time to drop them for 0.14.
They were not used anywhere in Talos, so no changes on Talos side.
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
Our CI amd64 builders are 3-4 times faster to build Talos than our arm64
builders when building Talos.
Our Dockerfile was restructured a while ago to support cross-compilation
on all platforms but CI was still using amd64/arm64 workers, so arm64
part was done on arm64 builders.
As our CI runs on Talos, `binfmt_misc` is not enabled in the kernel, but
buildkit has built-in QEMU emulation layer which works just fine for
those small pieces which actually need to run arm64 binaries on amd64
(mostly `apk add` in the installer container). Interesting enough,
buildkit QEMU support fails for `ca-certificates` script which runs
after install. At the same time I believe we don't need
`ca-certificates` in the installer, as installer doesn't download
anything from the network, and `ca-certificates` were added a while ago
when installer was actually downloading configuration on its own.
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
Note: Talos can be still run under `Firecracker`, support for
Firecracker was only removed for `talosctl cluster create`.
Reason:
* code is untested/unmaintained, and probably doesn't work correctly
* firecracker Go SDK pulls lots of dependencies and it blocks CNI Go
module update
Bonus: `talosctl-linux-amd64` shrinks by 2 MiB.
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
KubeSpan manager uses list of KubeSpan peers prepared from the discovery
and local KubeSpan identity to set up and update configuration of the
Wireguard interface.
As new peers are getting added or deleted, manager takes care of
updating the Wireguard config.
Manager also keeps track of all peers and their state coming from the
Wireguard link status: whether the connection is up or not, some stats,
last actually used endpoint, etc.
Manager cycles through the available peer endpoints until it finds the
one which works.
Manager exposes peer status as `PeerStatus` resources.
Example:
```
$ talosctl -n 172.20.0.2 get kubespanpeerstatuses
NODE NAMESPACE TYPE ID VERSION LABEL ENDPOINT STATE RX TX
172.20.0.2 kubespan KubeSpanPeerStatus GpO3gs5n09WpoiVANbzRL5nwrkRi+9Q19qoeC8RTkQ4= 30 talos-default-worker-2 172.20.0.6:51820 up 640 1920
172.20.0.2 kubespan KubeSpanPeerStatus j4CRlKByMcTWOBS2ifZcPzcUr3lXdBOc/I4AxGmhXxI= 30 talos-default-worker-1 172.20.0.5:51820 up 672 1888
172.20.0.2 kubespan KubeSpanPeerStatus o5EPScFrD895A5EpVyKU8hFR+vi25D0CJMYsoaXN3Qk= 28 talos-default-master-3 172.20.0.4:51820 up 640 1920
172.20.0.2 kubespan KubeSpanPeerStatus rBp5wyHdxqZkq5CWher2DcPcGgwHrFOwB6fP/ReFRlE= 16 talos-default-master-2 172.20.0.3:51820 up 432 2088
```
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
Signed-off-by: Seán C McCord <ulexus@gmail.com>
Co-authored-by: Seán C McCord <ulexus@gmail.com>
Also downgrade some indirect dependencies that don't have a good reason to be updated.
Closes#4111.
Closes#4112.
Closes#4116.
Closes#4117.
Closes#4121.
Closes#4122.
Signed-off-by: Alexey Palazhchenko <alexey.palazhchenko@talos-systems.com>
This relies on changes in GRUB and other utilities to respect
`SOURCE_DATE_EPOCH`.
Variable `SOURCE_DATE_EPOCH` is set to the timestamp of the last git
commit which makes it deterministic, but still changes for each
release/commit.
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
GCP does not consider generated .tar file to be valid.
This reverts commit b2507b41d250b989b9c13ad23e16202cd53a18d2.
Refs #4023.
Signed-off-by: Alexey Palazhchenko <alexey.palazhchenko@talos-systems.com>
Use `vtprobuf` optimized Marshal/Unmarshal methods which do not depend
on reflection to reduce memory and CPU usage while using Talos API.
See https://github.com/planetscale/vtprotobuf and
https://vitess.io/blog/2021-06-03-a-new-protobuf-generator-for-go/
Co-authored-by: Andrey Smirnov <smirnov.andrey@gmail.com>
Signed-off-by: Andrey Smirnov <smirnov.andrey@gmail.com>
Signed-off-by: Alexey Palazhchenko <alexey.palazhchenko@talos-systems.com>
Sparse file generation replaced with Go native calls.
Final artifact `.tar` reproducible with new tar flags and using GNU tar
instead of busybox one, but as the image itself is not reproducible,
this only helps a bit.
Signed-off-by: Andrey Smirnov <smirnov.andrey@gmail.com>
Resources code extensively uses DeepCopy to prevent in-memory copy of
the resource to be mutated outside of the resource model.
Previous implementation relied on YAML serialization to copy the
machine configuration which was slow, potentially might lead to panics
and it generates pressure on garbage collection.
This implementation uses k8s code generator to generate DeepCopy methods
with some manual helpers when code generator can't handle it.
Signed-off-by: Andrey Smirnov <smirnov.andrey@gmail.com>
