Skip to content

v2026.10.0 release candidate

Target release date: 2026-10-01
Status: unpublished release candidate

Comparison baseline: published v2026.9.2. Release preparation starts from merged main commit 15c14d7d; the final reviewed preparation commit must be recorded in the readiness ledger before tagging.

This page describes the planned October release. It is not a release artifact reference until the tag, images, chart, checksums, and signatures appear on the public Releases page.

What changes for operators since September

  • Secure IOS-XE gNOI supports password authentication metadata and explicit certificate provisioning for the OS service. Verified TLS and provisioning trust are scoped to gNOI; this is not a global transport or gNMI security bypass. Read-only OS.Verify does not install certificates. See gNOI and Software Lifecycle and the upgrade/downgrade runbook.
  • Devices can project administrator-controlled topology labels into native Kubernetes Nodes. Affinity and topology-spread constraints place eligible application workloads; CVK's rollout controller separately uses frozen topology domains and budgets to order device software changes. Kubernetes scheduling alone does not decide whether a network path is safe to interrupt.
  • IOSXESoftwareRollout provides immutable, approved multi-device plans, canaries, domain/concurrency budgets and topology-specific image sources. This is a combined transfer/activation/recovery workflow, not separately approved durable staging.
  • Managed workers use two functional ServiceAccounts (app-hosting and network-management), with read-only/read-write role options, rather than a ServiceAccount for every device. Admission/worker binding is part of the security boundary; RBAC alone is not per-device authorization.
  • PDB-aware drain remains a disabled-by-default development preview for the documented supported workload subset. It is not general-purpose evacuation or a guarantee of application/network continuity.
  • Dependency updates include OpenTelemetry logging migration and golang.org/x/crypto. CI/lab execution has correlated lifecycle telemetry; that telemetry is diagnostic evidence, not proof of complete qualification.
  • Release preparation updates the documentation website to Next.js 16.3.8 and fixes affected transitive dependencies; see the readiness ledger for audit results and the separate remaining container/security gates.

Merged scope: PRs #184–#188 and #190–#194. No code from the subsequent pr/johalley/tas-extentions November roadmap is included by this preparation.

Release scope

The release candidate combines the Kubernetes-native topology foundation with the first IOS-XE rollout capabilities:

  • manager-owned CiscoDevice-to-Node identity and bounded topology projection;
  • native scheduler affinity and topology-spread placement;
  • immutable IOS-XE rollout plans with topology-domain budgets, canaries, and pause/cancel recovery;
  • topology-scoped image endpoint selection with frozen endpoint, digest, and Secret identity per target;
  • secure gNOI transfer, activation, and verification through the existing IOS-XE software lifecycle; and
  • an opt-in, PDB-aware Eviction drain for the explicitly supported workload subset.

The rollout and drain APIs remain alpha/preview contracts. Managed topology, write-class gNOI, and workload drain are disabled by default and require the administrator to opt in after completing the admission and rollback checks in the managed topology guide.

Compatibility boundary

  • Kubernetes 1.35 is the CVK support floor for managed topology.
  • Kubernetes 1.37 native TAS has a separate experimental scheduler-conformance lane. Fixture scheduler tests do not establish the full physical CVK group lifecycle; TAS is not a CVK runtime dependency or enabled by default.
  • The public rollout implementation in this release is IOS-XE-specific. NX-OS and IOS-XR do not receive a generic rollout API from this release.
  • The physical qualification evidence covers the IOS-XE lab fleet used by the project. It does not establish multi-site fault tolerance, zero-downtime guarantees, or cross-platform production support.

Upgrade and rollback

Existing Helm installations must apply all reviewed CRDs from the pinned October chart before the controller upgrade; Helm does not upgrade CRDs. Compared with September, IOSXESoftwareRollout is new and CiscoDevice, IOSXESoftwareUpgrade and IOSXEOperationalAction schemas change. Follow the CRD upgrade procedure, back up both schemas and custom resources, and test stored-object compatibility first.

Keep managed topology, software mutation and drain disabled unless deliberately adopting their qualified scope. Before enabling them, validate native admission, functional-account permissions, exact ownership and the opt-in migration steps in the managed topology guide. Do not overlap old and new workers' device authority or drop guards on unresolved operations.

Rolling back the chart does not roll back schemas, restore discarded fields, or undo a device activation. Never delete CRDs, claims, Leases or retained operation history as a shortcut. Use the documented recovery procedure and verify device/app state separately from Pod readiness.

Known qualification limits / publication hold

This candidate is not yet approved for tagging. The readiness ledger must link exact-candidate CI, API/admission, migration and physical evidence. Later dirty November-development builds exposed delayed drain callbacks, stale Running Pod cleanup markers and stopped evidence collectors. Those runs neither prove this exact main candidate faulty nor certify it safe. Before publication, reproduce/triage that lifecycle on the October candidate and either qualify a minimal reviewed fix or make an explicit reviewed scope decision; do not silently inherit November fixes or declare preview drain production-qualified. Independent endpoint/forwarding continuity remains unproven, and unsupported package/storage/signing cases must stay explicit.

Required release gates

The release candidate must be cut from the final merged commit, not from an intermediate stacked branch. Before tagging, maintainers must record passing results for:

  1. go test ./... and go test -race ./...;
  2. go vet ./..., build, and go mod verify;
  3. generated deepcopy/CRD/RBAC parity and Helm lint/render checks;
  4. the Kubernetes 1.35 real-API admission and default-scheduler suite;
  5. secure gNOI upgrade and downgrade validation on the supported IOS-XE lab devices, including final Node, Pod, PDB, Lease, reservation, and device inventory evidence;
  6. strict documentation build; and
  7. vulnerability and dependency checks on the exact release commit.

Do not publish while a release check is failing or while a dependency update has an unresolved vulnerability result. A failed dependency PR must be fixed or explicitly deferred in the release decision; it must not be merged merely to unblock the feature stack.

Operational expectations

The supported upgrade path is a controlled relocation protocol. It protects eligible Pods with Kubernetes Eviction and PDB semantics, waits for the exact post-termination device inventory evidence, and releases the protection only after the manager's fencing Lease and worker observations are settled. It is not a promise of uninterrupted network forwarding or zero downtime.

Operators should retain the following evidence for every production change:

  • the applied rollout and approval manifests;
  • campaign and per-device phase transitions;
  • CVK manager and worker logs with secret material redacted;
  • IOS-XE console and show command evidence;
  • final topology, Node, Pod, PDB, Lease, and reservation state; and
  • the exact image digest and source endpoint selected for each target.

Deferred roadmap

The following work is intentionally outside this release:

  • durable image prefetch, shared cache, and cache-loss recovery;
  • independently durable install/stage/activate reservations and resumable activation;
  • general-purpose workload evacuation for StatefulSets, DaemonSets, Jobs, PVC-backed workloads, or custom controllers;
  • an authoritative discovered topology graph or graph-cost scheduler;
  • mandatory native Workload/PodGroup/TAS integration;
  • generic NX-OS or IOS-XR rollout APIs;
  • multi-cluster ownership and cross-controller fencing; and
  • automated routing, forwarding, utilization, and critical-service health gates.

The shipped behavior is documented in the topology guide. The separately preserved November handoff and roadmap tracks future implementation and testing; it is not part of October qualification.