fix(core): bump builder/golang-alt-1.25 toolchain#2541
Merged
Conversation
…e-migration A/B Override the virt-artifact build stage to use the pre-CVE toolchain (registry.deckhouse.io/base_images@sha256:e25c039, ALT 20250625 / go1.25.10, the v1.8.3 base) directly via 'from:', bypassing the base-images pin that switches builder/golang-alt-1.25 to the ALT 20260119 toolchain. Only virt-artifact is affected; dvcr-artifact and other images keep the new toolchain (their go.mod requires go >= 1.25.11). installCacheVersion forces a rebuild. Test-only; revert before merge. Signed-off-by: Pavel Tishkov <pavel.tishkov@flant.com>
0b5f558 to
c94b442
Compare
…(b370cc95) Switch the virt-artifact build stage from the pinned go1.26.4 toolchain (71dffc9, slow per bench) to dev-registry.deckhouse.io/container-factory@ sha256:b370cc95 (go1.25.11 + greenteagc). Isolated TLS bench on this image: AES-GCM 3648 MB/s, TLS 1.3 forced 22673 Mbit/s, TLS 1.2 forced 27471 Mbit/s (cipher negotiated = TLS_AES_128_GCM_SHA256; GOST suites present but not selected). No regression vs the slow 713b7c2 toolchain (49 Mbit/s in diary). Dev-only: image lives in dev-registry.deckhouse.io/container-factory, not yet pushed to prod registry.deckhouse.io/container-factory. Revert to fromImage: builder/golang-alt-1.25 once b370cc95 is available in prod. Signed-off-by: Pavel Tishkov <pavel.tishkov@flant.com>
…th GOST TLS fix Switch the virt-artifact build stage from the slow go1.26.4 toolchain (71dffc9) to the dev-registry ALT toolchain 78a55067 (registry.altlinux.org/p11/alt:20260119 base, go1.25.11 + greenteagc + gogost) which carries the GOST TLS priority fix from base-images branch go-gost-tls-priority. GOST cipher suites are no longer preferred in TLS 1.3 auto-negotiate, so AES-GCM is selected and live-migration throughput is restored. Isolated TLS bench on 78a55067 (vs the slow 713b7c2 at ~49 Mbit/s in the regression report): AES-GCM ~3600 MB/s, TLS 1.3 ~22000 Mbit/s, cipher negotiated = TLS_AES_128_GCM_SHA256. Dev-only: the image lives in dev-registry.deckhouse.io/container-factory and is not yet pushed to prod registry.deckhouse.io/container-factory. TODO tracked in the comment: once base-images go-gost-tls-priority is released to prod, revert this to fromImage: builder/golang-alt-1.25 and update the SHA in build/base-images/container_factory_images.yml. Signed-off-by: Pavel Tishkov <pavel.tishkov@flant.com>
…chain Bump builder/golang-alt-1.25 in container_factory_images.yml from the slow 713b7c2 (registry.altlinux.org/p11/alt:20260119 + go1.25.11 + greenteagc + gogost, GOST cipher suites preferred in TLS 1.3 auto-negotiate -> Kuznyechik software path -> ~49 Mbit/s in the isolated TLS bench, ~300 Mbps in cluster live migration) to 603fbc50. The new 603fbc50 image is built from the same ALT 20260119 base and carries the GOST TLS priority fix from base-images branch go-gost-tls-priority: gogost v6 stays registered, but GOST cipher suites are no longer preferred, so TLS 1.3 auto-negotiate picks AES-GCM (AES-NI) again. Isolated TLS bench on 603fbc50: AES-GCM ~3578 MB/s, TLS 1.3 ~15838 Mbit/s, cipher negotiated = TLS_AES_128_GCM_SHA256. virt-handler's Go crypto/tls migration proxy is the data path for all multifd RAM traffic (pkg/virt-handler/migration-proxy/migration-proxy.go), so the toolchain GOST regression hit live-migration throughput directly. Cluster validation on the 'virt' cluster (injector VM, 8Gi, TLS on): MemoryBandwidth avg ~1013 Mbps / peak 1328 Mbps (vs regressed ~300 Mbps, vs v1.8.3 ~942 Mbps). Live migration Succeeded in ~25s. Reverts images/virt-artifact/werf.inc.yaml to the regular fromImage: builder/golang-alt-1.25 (the previous from: override pinned a dev-registry image and is no longer needed now that 603fbc50 is in prod registry.deckhouse.io/container-factory). The base-images-pins.yml entry routing builder/golang-alt-1.25 to container_factory stays: the new SHA lives there. Signed-off-by: Pavel Tishkov <pavel.tishkov@flant.com>
Restore the original fromImage ternary expression that was inadvertently simplified when reverting the dev-registry from: override. The expression keeps the SVACE_ENABLED branching shape intact even though both branches currently resolve to the same image. Signed-off-by: Pavel Tishkov <pavel.tishkov@flant.com>
Signed-off-by: Nikita Korolev <141920865+universal-itengineer@users.noreply.github.com>
universal-itengineer
approved these changes
Jun 26, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
Bumps
builder/golang-alt-1.25inbuild/base-images/container_factory_images.ymlto the latest build and revertsimages/virt-artifact/werf.inc.yamlto the regularfromImage: builder/golang-alt-1.25(removes the temporaryfrom:override from the previous iteration).Why do we need it, and what problem does it solve?
Picks up the latest
builder/golang-alt-1.25toolchain build, which resolves a live-migration throughput regression observed between v1.8.3 and v1.9.1. With the previous toolchain build, live migration of a running VM with TLS enabled was noticeably slower. The new build restores the expected throughput.What is the expected result?
VirtualMachineOperationtypeMigrate).VirtualMachineOperationreachesCompleted/migrationState.result=Succeededwith throughput restored to the v1.8.3 level.Checklist
VirtualMachineOperationCompleted/Succeededin ~25 sChangelog entries