Tags give the ability to mark specific points in history as being important
-
v0.6.1
Release: CAPVCO v0.6.17ec7347e · ·CAPVCO v0.6.1 Surviving clusterctl move. Four defects found by an external Sylva integration run against v0.6.0, three of which made an unattended pivot impossible — and a Sylva management bootstrap ends in a clusterctl move by design. - #40 providerID was recomputed from machine.UID on every reconcile, so a move rewrote it while the Node kept the original and CAPI reported healthy Nodes as NodeDeleted. Kubernetes forbids correcting a Node's providerID, making it a one-way door. Now assigned once and never changed. - #39 ensureLoadBalancer created what it should have discovered. A move drops status by design, so it retried CreateServerPool against a pool that already existed, forever. The backend is now the source of truth and status a cache: both objects are discovered by name, and a create conflict resolves by discovery. - #44 adopting a cloudspace by name had no ownership check, so a duplicate VCOCluster could adopt live infrastructure and destroy it on delete. Not blocked — the backend cannot distinguish a duplicate from a legitimate recovery — but now recorded in status.cloudspaces[].adopted and surfaced as an AdoptedLiveCloudspace warning event when the adopted cloudspace already runs VMs. - #41 a credential value with a trailing newline broke Authorization header construction. All credential fields are now trimmed at ingestion. Also: a e2e scenario, the twelfth feature-matrix cell. Nothing had ever performed a clusterctl move, which is exactly why #39 and #40 reached a release. It moves a loadbalancer-exposed cluster to a second management cluster and asserts the infrastructure is adopted rather than recreated and that no provider id changes on either side. Green on real hardware. Documented: installing CAPVCO with GitOps instead of clusterctl (#47, #50) — clusterctl move refuses without Provider inventory records, and a manager image override must match the post-transformation name. Still open and not ours to land: the VCO backend 502 (#42) and Sylva chart support (#43). Unchanged known limitations: RWO volumes are not single-node-safe (#22) and encrypted volumes need cryptsetup in the CSI image (#32).
-
v0.6.0
Release: CAPVCO v0.6.0de298a37 · ·CAPVCO v0.6.0 GPU workloads verified on real hardware, supported Kubernetes versions, and automatic worker scaling. - GPU workload tier (#34): a pod consuming a real NVIDIA L4, end to end. Root cause of the long-standing failure was the platform mapping the card's 32GiB BAR1 above the guest CPU's 40 physical address bits; every node image is now GPU-ready (pci=nocrs pci=realloc), and a real-GPU CI job keeps it proven. - Supported Kubernetes versions (#28): v1.35.8 / v1.36.4 / v1.37.0. The shipped v1.30.14 and v1.31.5 were EOL by 14 and 10 months. Brings clusterctl v1.14.2, kind v0.33.0, cert-manager v1.21.1, and the provider now builds against cluster-api v1.14.2. Resolves #38. - Automatic worker scaling (#24): cluster-autoscaler via the clusterapi provider, including scale to and from zero, backed by VCOMachineTemplate.status.capacity. Validated on a real backend by 11 feature-matrix scenarios per merge request. Known limitations unchanged and documented: RWO volumes are not single-node-safe (#22) and encrypted volumes need cryptsetup in the CSI image (#32) — both driver-side.
-
v0.5.0
Release: CAPVCO v0.5.035658a71 · ·CAPVCO v0.5.0 — GPUs by type, and SR-IOV networking per pod Two features, both validated end to end against a real whitesky.cloud backend. GPUs (#34). A machine pool asks for a GPU by TYPE, not by instance: gpu: type: "NVIDIA A100" count: 1 driverVersion: "550" # empty for a pre-baked image The provider resolves that type against the location's per-card profiles, reserves and attaches in a single call, records every reservation the moment it exists, and releases them all on teardown. A vGPU is billed from the moment it is reserved — detaching one does not stop the charge — so ownership is encoded in the reservation name and cluster teardown reclaims every reservation it owns, attached or not, including those left behind by a machine deleted with --force. `capvco-gpucheck -orphans` reports anything that still escapes. SR-IOV networking (#27). Pods get a NIC on an external network on demand, at CNI time, instead of pre-attaching scarce virtual functions to every node. A DaemonSet agent holds the credential and serialises attaches per VM; a host-side CNI plugin moves the interface into the pod's namespace and configures the address the platform assigned, leaving the default route with the primary CNI. NICs are reclaimed when a pod goes, including pods that died without a CNI DEL. The agent's credential is supplied by the operator and never defaulted to the cluster credential. Also in this release: first-boot package installs are retried and fail loudly rather than producing a node that never joins; the feature-matrix e2e runs one job per scenario, individually retryable; and the e2e now tests the branch's own in-workload images rather than master's. Not yet covered: a pod actually consuming a GPU (driver, device plugin, nvidia-smi) needs GPU hardware this platform does not offer — see #34 and #37. Upgrade notes: none. Both features are opt-in — GPUs via spec.gpu on a machine template, SR-IOV via the add-on label plus spec.sriov.credentialSecretRef. Full detail in !12; limitations in docs/known-limitations.md. -
v0.4.0
Release: CAPVCO v0.4.052e35e87 · ·v0.4.0 — geo redesign + #33 bootstrap fix, backup/air-gapped fixes, feature-matrix e2e gate Validated by a new 8-scenario feature-matrix e2e on a real backend (#18) — RWO enforcement, HA, CCM, geo, rolling minor upgrade, etcd backup/restore, pre-baked images, air-gapped — now a required MR gate. It surfaced every fix below. Closes #33. BREAKING — geo templates and the CNI add-on: - The `geo-multilocation` flavor is gone. One `cluster-template-geo.yaml` now declares 3 sites; whether they share a location or straddle datacenters is a per-site property, not a different cluster shape. - Geo variables are per-site: GEO_SITE{1,2,3}_{LOCATION,IMAGE_ID,EXTNET_ID} replace GEO_LOCATION, GEO_PRIMARY_LOCATION, GEO_PAIRED_LOCATION, VCO_IMAGE_ID_PRIMARY, VCO_IMAGE_ID_PAIRED, VCO_PRIMARY_EXTNET_ID and VCO_PAIRED_EXTNET_ID. - Geo site keys are positional (site-1..3), independent of how cloudspaces map to locations — so CAPI failure-domain names and the per-site DNS records <cluster>-site-N.<zone> change. - The `cni-geo` bundle is gone: one geo-tuned `cni.yaml` (veth_mtu 1350) serves every cluster, and the geo/ccm/backup/airgapped templates label clusters `cni: calico` instead of `cni: calico-geo`. Fixes: - geo (#33): `kubeadm init` on the bootstrap node no longer waits on the health-aware control-plane endpoint — the init node pins the endpoint name to its local apiserver in /etc/hosts, so wait-control-plane succeeds and the post-init addon phases (kube-proxy, CoreDNS) actually run. A cross-datacenter geo cluster whose bootstrap CP landed outside the primary location used to hang until the 60m timeout. - geo: the endpoint A record is published only once a site is genuinely healthy (NXDOMAIN until then) instead of being parked at the primary cloudspace IP, so the first address anyone resolves is always a live control plane — no stale placeholder for a caching resolver or a pinned CAPI client to latch onto. - backup: snapshots run as root, status.backup records the newest uploaded snapshot (key + time), and the restore path accepts a full age identity file rather than only a bare AGE-SECRET-KEY line. - air-gapped: ships a seeded zero-egress registry image, and ensuring the registry's certificate tolerates a 400 "already exists" from the backend. Also: new `capvco-imageresolve` CLI (resolve a vm-image id by name, per location). CRD schemas are unchanged — contract stays v1beta2; the base and prebaked templates are untouched. -
v0.3.0
Release: CAPVCO v0.3.0dd7dc984 · ·v0.3.0 — explicit external network (#29), CSI driver-name derivation (#21), required e2e gate (#17), RWO enforcement docs (#22)
-
v0.2.2
Release: CAPVCO v0.2.22a18fa84 · ·v0.2.2 — getting-started works on any supported k8s version; service-LB #23 fix; e2e on real backend; CI/docs fixes
-
v0.2.1
Release: CAPVCO v0.2.1b5470720 · ·CAPVCO v0.2.1 — fix v0.2.0 clusterctl dead-drop (metadata 0.2 series) + gate releases on pre-publish bundle validation
-
v0.2.0
Release: CAPVCO v0.2.0ac242bf9 · ·CAPVCO v0.2.0 — getting-started fixes: ship CNI/CSI add-on bundles (#14), require location-specific image ids (#13), worker-count docs (#15), docs logo (#12)
-
v0.1.3
Release: CAPVCO v0.1.338235480 · ·CAPVCO v0.1.3 First release with the corrected getting-started docs and the fixed manager (#7: no standing credential — capvco-credentials needs only portalUrl + iamRefreshUrl). Node images built via parallel:matrix.
-
v0.1.2
Release: CAPVCO v0.1.25fe94d64 · ·CAPVCO v0.1.2 — first release under the public whitesky-oss project Ships the clusterctl provider bundle, cluster templates, the capvco CLIs, and pre-baked node VM images (v1.30.14, v1.31.5). First release after the transfer to git.gig.tech/whitesky-oss and going public.