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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Uses Sidero Labs d2ctl to install a small sample of
common cluster services to ensure the Talos cluster
is capable.
Signed-off-by: Tim Jones <tim.jones@siderolabs.com>
This is needed to make sure that those steps don't run in parallel on
release builds, as they write same output files.
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
Fixes#4947
It turns out there's something related to boot process in BIOS mode
which leads to initramfs corruption on later `kexec`.
Booting via GRUB is always successful.
Problem with kexec was confirmed with:
* direct boot via QEMU
* QEMU boot via iPXE (bundled with QEMU)
The root cause is not known, but the only visible difference is the
placement of RAMDISK with UEFI and BIOS boots:
```
[ 0.005508] RAMDISK: [mem 0x312dd000-0x34965fff]
```
or:
```
[ 0.003821] RAMDISK: [mem 0x711aa000-0x747a7fff]
```
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
Fixes#4694
User services run alongside with Talos system services.
Every user service container root filesystem should be already present
in the Talos root filesystem.
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
As `_out` is a shared volume across Drone steps, we should prefetch CLI
dependencies early, as fetching them concurrently from multiple steps
might lead to surpising results.
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
Fixes#4816
This changes the way system extensions are packaged into the squashfs
images: `/lib/firmware` is now moved out of the future squashfs images
and becomes part of `initramfs` to make firmware available in the early
boot.
Talos will bind-mount `/lib/firmware` into rootfs as well, so it will be
available in the rootfs as well.
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
Instead, build all images for a release and in the integration pipeline
which is triggered `nightly` and can be promoted to with
`/promote integration-images`.
This saves time and resources on regular builds.
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>
This fixes the issue with kubelet picking up wrong IP on restart, as
Talos doesn't know pod IPs (Cilium is using its own pod CIDR, it doesn't
look up Kubernetes settings).
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
This enables cluster discovery by default for Talos 0.14. KubeSpan is
not enabled by default.
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>
We use hacked version with a workaround for capability issues with
`--privileged` in Docker.
See moby/moby#42906
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
* cloud-init for scaleway
* set ipv6 to the interface
Signed-off-by: Serge Logvinov <serge.logvinov@sinextra.dev>
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
* cloud-init for hcloud
* set ipv6 to the interface
Signed-off-by: Serge Logvinov <serge.logvinov@sinextra.dev>
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
Race-detector enabled image is pushed with a tag next to normal image,
regular integration test is ran against the image.
Signed-off-by: Andrey Smirnov <andrey.smirnov@talos-systems.com>
GitHub recently introduced limit of 25000 byte for the release notes,
which breaks our release process, as our notes are over the limit.
PR https://github.com/talos-systems/talos/pull/4021 introduced support
for GFM release notes, which are at least 50% smaller.
This PR enables GFM, adds a check for release notes size and pushes
release-notes step to every build so that we known in advance if release
notes are over the limit (vs. the moment we push the release).
Signed-off-by: Andrey Smirnov <smirnov.andrey@gmail.com>
This PR updates our CI so that when we release talos, a json file
containing our cloud images for AWS will be published as a release
asset.
Signed-off-by: Spencer Smith <robertspencersmith@gmail.com>
Initialize state should be only reading the config.
So now if it detects that the partition is not even formatted it will
skip it and will consider the state to be empty.
Signed-off-by: Artem Chernyshev <artem.0xD2@gmail.com>
This fixes the dependency in the nightly run to make sure artifacts are
rebuilt fresh before triggering conformance run (every other step did
that, but not this one).
Signed-off-by: Andrey Smirnov <smirnov.andrey@gmail.com>
Apparently, I submitted non working board support earlier. This commit
fixes that and also adds the boards to both `sbcs` target and drone CI.
Signed-off-by: Jorik Jonker <jorik@kippendief.biz>
This has two big visible changes:
* `installer` image now contains assets for both `amd64` and `arm64`, so
it can be used to generate any Talos image (including RPi on amd64 host)
* Talos is using cross-compilation instead of emulation to build
non-native architectures: on amd64, Go amd64 compiler produces binaries
for both arm64 and amd64
(before this change: Go arm64 compiler via QEMU produces arm64 binaries on amd64)
CI implications: we no longer require arm64 nodes.
Changes walkthrough:
* `installer` container now keeps assets under `/usr/install/<arch>`
* Dockerfile build starts forcing toolchain/base image to use the build
host native architecture, not target architecture
* lots of duplication for amd64/arm64 as we want to combine assets for
both arches in a single image (e.g. we have multi-arch amd64/arm64
installer image, each arch has native installer binary, but both arches
contain full set of amd64/arm64 assets)
* fixed a small bug preventing arm64 on amd64 talosctl cluster create
Signed-off-by: Andrey Smirnov <smirnov.andrey@gmail.com>
Command implements two modes:
* `fast`: conformance suite is run at maximum speed
* `certified`: conformance suite is run in serial mode, results
are capture to produce artifacts ready for CNCF submission process
Signed-off-by: Andrey Smirnov <smirnov.andrey@gmail.com>
This adds a VIP (virtual IP) option to the network configuration of an
interface, which will allow a set of nodes to share a floating IP
address among them. For now, this is restricted to control plane use
and only a single shared IP is supported.
Fixes#3111
Signed-off-by: Seán C McCord <ulexus@gmail.com>
Signed-off-by: Andrey Smirnov <smirnov.andrey@gmail.com>
Verify upgrade flow using the same version of the installer.
Run that with disk encryption enabled.
Signed-off-by: Artem Chernyshev <artem.0xD2@gmail.com>
This adds new `IMAGE_REGISTRY` variable (similar to `IMAGE_TAG`) which
affects only the registry image gets pushed to, but it's not built into
the binaries and images as a default registry.
This fixes a problem when release builds reference our CI local
registry.
Signed-off-by: Andrey Smirnov <smirnov.andrey@gmail.com>
This makes sure artifacts will allways be built as part of
the scheduled run, even if latest merge to master happened just before
the scheduled build.
Signed-off-by: Andrey Smirnov <smirnov.andrey@gmail.com>
