chore(deps): update dependency longhorn/longhorn to v1.12.0#902
Open
renovate[bot] wants to merge 1 commit into
Open
chore(deps): update dependency longhorn/longhorn to v1.12.0#902renovate[bot] wants to merge 1 commit into
renovate[bot] wants to merge 1 commit into
Conversation
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.
This PR contains the following updates:
v1.11.2→v1.12.0Release Notes
longhorn/longhorn (longhorn/longhorn)
v1.12.0: Longhorn v1.12.0Compare Source
Longhorn v1.12.0 Release Notes
The Longhorn team is excited to announce the release of Longhorn v1.12.0. This feature release marks a major milestone for Longhorn: the V2 Data Engine is now officially Generally Available (GA).
With the V2 Data Engine reaching GA, Longhorn v1.12.0 strengthens the production story for modern workloads with topology-aware provisioning, dual-stack and V2 IPv6 support, improved observability and operational tooling, and clearer guidance around V1 and V2 behavior and feature parity.
For terminology and background on Longhorn releases, see Releases.
Removal
V2 Backing Image Removal
V2 Backing Images are removed in Longhorn v1.12.0. Suggest using the Containerized Data Importer (CDI) to import VM disk images into V2 volumes to achieve the same purpose.
If you have V2 volumes that were created from backing images, you must migrate them before upgrading to v1.12.0:
V2 volumes with backing image dependencies cannot be upgraded in-place. Attempting to upgrade without migration may result in volume attachment failures.
GitHub Issue #13181
Primary Highlights
V2 Data Engine
Generally Available
We are pleased to announce that the V2 Data Engine has officially graduated to General Availability in Longhorn v1.12.0.
This milestone reflects major progress in stability, operational safety, networking support, and feature maturity. Compared with earlier releases, V2 volumes are better positioned for production use, combining GA readiness with modern networking support, more precise scheduling behavior, and clearer visibility into where V2 already matches V1 behavior and where differences still matter.
For a summary of the current V1 and V2 volume behavior differences and feature parity, see V1 and V2 Volume Feature Support.
Looking ahead, the roadmap remains active: fast volume cloning for V2 data engine (#12552) and Sharding Storage (Experimental Feature) (#1061) are planned for Longhorn v1.12.1.
Smarter Provisioning and Modern Networking
Topology-Aware PV Node Affinity Control
Longhorn v1.12.0 adds the
csi-allowed-topology-keyssetting andstrictTopologyStorageClass parameter for more precise control of PVnodeAffinity. These options allow users to limit which topology keys are propagated and, withWaitForFirstConsumer, pin the PV to the selected node topology when needed.GitHub Issue #12684
IPv6 Support for V2 Volumes
V2 volumes now support single-stack IPv6 Kubernetes clusters.
GitHub Issue #10928
Dual-Stack Cluster Support
Longhorn now supports dual-stack Kubernetes clusters when all nodes are configured with their IP families in the same order, either all IPv4-first or all IPv6-first. This applies to both the V1 and V2 data engines.
GitHub Issue #11531
Better Operations and Observability
Default CPU Allocation
Longhorn v1.12.0 changes the default
data-engine-cpu-maskfrom0x1, one CPU core, to0x3, two CPU cores. V2 Data Engine uses a busy-polling reactor model where the master reactor handles both I/O polling and management RPCs. When only a single core is assigned, heavy I/O workloads can delay or starve RPC processing, resulting in increased latency, timeout events, and operational instability.Assigning two or more cores allows I/O and management tasks to run on separate reactors, improving responsiveness and operational stability.
GitHub Issue #13237
On-Demand Snapshot Checksum Calculation
Longhorn v1.12.0 adds
longhornctlsupport for triggering on-demand snapshot checksum calculation. The command can target a specific volume, all volumes on a specific node, or all volumes in the cluster, and the checksum operation runs asynchronously in the background.GitHub Issue #11442
Toggle Kubernetes Metrics Server Integration
Longhorn v1.12.0 adds the
Kubernetes Metrics Server Metrics Enabledsetting to disable metrics-server-dependent metrics when the Kubernetes Metrics Server API is unavailable. This reduces repeated scrape warnings and unnecessary API calls while preserving other Longhorn metrics.GitHub Issue #13011
Longhorn Manager Memory Optimization
Longhorn v1.12.0 optimizes longhorn-manager informer caching to reduce memory usage, especially in large clusters with high pod counts. This lowers cluster-wide memory overhead caused by repeated caching of non-Longhorn pod data on every manager instance.
GitHub Issue #12771
Configurable Engine Image Pod Liveness Probe
Longhorn v1.12.0 adds settings to configure the engine-image DaemonSet liveness probe period, timeout, and failure threshold. These settings help reduce unnecessary engine-image pod restarts on resource-constrained clusters, especially during upgrades or transient CPU spikes.
GitHub Issue #12846
Critical Stability Fixes
Instance Manager Stability During Replica Rebuild Storms
Longhorn v1.12.0 fixes an instance-manager panic that could occur during replica rebuild storms. In affected environments, the panic could terminate all iSCSI targets served by the instance-manager and trigger cascading volume detachments across multiple PVCs.
GitHub Issue #13087
Replica Rebuild Progress Reporting
Longhorn v1.12.0 fixes a replica rebuild progress reporting bug that could display values greater than 100% after file-sync retries on unstable networks. Progress accounting is now reset correctly for retried files, so rebuild progress remains within the valid 0% to 100% range.
GitHub Issue #12949
Replica Auto-Balance Scheduling Loop
Longhorn v1.12.0 fixes a regression in replica auto-balance that could trigger a repeated replica create-and-delete loop when
Replica Auto Balancewas set tobest-effort. In affected clusters, Longhorn could keep scheduling an extra replica instead of stabilizing at the configured replica count.GitHub Issue #12926
Replica CR Leak During Failed Local Scheduling
Longhorn v1.12.0 fixes a replica scheduling issue where large numbers of stopped Replica CRs could accumulate when
dataLocalitywas set tobest-effortand the node did not have enough eligible local disk space for another replica. In affected clusters, recurring reconciliation could keep creating placeholder Replica CRs instead of reusing a single failed-schedule placeholder.GitHub Issue #13152
CSI Storage Capacity Tracking
Longhorn v1.12.0 fixes a CSIStorageCapacity scheduling issue that could cause compute nodes without Longhorn disks to report zero capacity and be rejected by
WaitForFirstConsumerscheduling. In affected clusters with separated compute and storage nodes, new PVCs could remain pending even though eligible storage was available on storage nodes.GitHub Issue #12807
Encrypted Volume Size Correction
Longhorn v1.12.0 pre-allocates the 16 MiB LUKS2 header in the replica backend file for encrypted volumes, so the dm-crypt device now exposes the full requested size to workloads after the engine image is upgraded.
This change also introduces an upgrade constraint for encrypted migratable volumes: live migration is not supported when using an engine image with a CLI API version older than 12. Upgrade the engine image to v1.12.0 or later before attempting live migration of encrypted volumes.
GitHub Issue #9205
UBLK Frontend Kernel Limitation
The UBLK frontend for V2 data engine volumes remains experimental and is only functional on Linux kernels below v6.17. On kernel v6.17.0 and above, UBLK fails due to upstream UBLK API changes that cause
EINVALerrors when starting UBLK devices.GitHub Issue #11977
Installation
You can install Longhorn using a variety of tools, including Rancher, Kubectl, and Helm. For more information about installation methods and requirements, see Quick Installation in the Longhorn documentation.
Upgrade
Longhorn only allows upgrades from supported versions. For more information about upgrade paths and procedures, see Upgrade in the Longhorn documentation.
Post-Release Known Issues
For information about issues identified after this release, see Release-Known-Issues.
Resolved Issues in this release
Highlight
Feature
--tolerationsflag tolonghornctlfor scheduling DaemonSet pods on tainted nodes 12993 - @chriscchien @bachmanity1Improvement
distroin chart tolonghorn13160 - @derekbit @chriscchienTooManySnapshotsvolume condition uses a hard-coded threshold despite configurable snapshot max count 12396 - @COLDTURNIP @yangchiuTooManySnapshotsvolume condition uses a hard-coded threshold despite configurable snapshot max count 12922 - @chriscchien @houhoucoopBackup Targetto volume listcustom columnoptions 12619 - @yangchiu @houhoucoopendpoint-network-for-rwx-volumevalidation for migratable block-mode volumes 12644 - @c3y1huang @chriscchienBug
/dev/disk/by-path/pci-*path fails (should use aio driver, but incorrectly thinks it's a BDF path) 13228 - @tserong @chriscchienDegradedstate after instance manager is deleted and restarted 13215 - @yangchiu @derekbitSpec.NodeIDbefore delete, potentially orphaning replicas whenStatus.InstanceManagerNameis empty 13198 - @derekbit @chriscchienAvailableafter being reset to empty 13195 - @yangchiu @derekbittest_cleanup_system_generated_snapshotsfails on v2 volumes 13123 - @yangchiu @davidcheng0922test_drain_with_block_for_eviction_if_contains_last_replica_successfailed on v1 volumes 13103 - @derekbit @chriscchiensnapshot-max-countdoesn't work on v2 volumes 12921 - @yangchiu @davidcheng0922Attachingstate 13084 - @yangchiu @derekbitverify()race overwritesreplicaMap, breaking concurrent replica rebuild 13074 - @derekbit @roger-ryaotest_support_bundle.pytest cases fail onhardened clusterwithIPv6 mode13066 - @COLDTURNIP @yangchiutest_delete_backup_during_restoring_volumefails on v2 volume, volume not faulted and condition Restore is True 13061 - @derekbit @chriscchienDegradedstate if replica rebuilding is triggered during incremental restoration 12515 - @davidcheng0922 @chriscchientest_rebuild_with_restorationis flaky on v2 volume 11447 - @derekbit @chriscchienlastBackupof a v2 volume may remain empty after a backup is created 12542 - @mantissahz @roger-ryaodd && synccommand hangs on v2 rwx encrypted volume 12649 - @mantissahz @chriscchientest_storage_capacity_aware_pod_schedulingfails 13001 - @yangchiu @bachmanity1test_replica_scheduler_rebuild_restore_is_too_bigcreates a volume with an incorrect data engine type. 12776 - @derekbit @chriscchienspdk_tgtencountered an assertion failure inlonghorn-spdk-helperduring a CI test run 10599 - @derekbit @roger-ryaoPerformance
Resilience
Stability
Misc
status.requestedTime13113 - @chriscchienpathswhen patching node viakubectl12480 - @yangchiu @carterli0407-cellConfigurable CPU Coresdescription 12740 - @chriscchien @sushant-suseNew Contributors
Contributors
Configuration
📅 Schedule: (UTC)
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
This PR was generated by Mend Renovate. View the repository job log.