stacklok / toolhive / 24729431797

push

github

Graduate CRDs from v1alpha1 to v1beta1 (#4849)

* Graduate CRDs from v1alpha1 to v1beta1

Signal API stability by promoting all ToolHive CRDs to v1beta1 while
preserving backwards compatibility — the CRDs serve both versions
simultaneously so existing v1alpha1 resources survive the upgrade
untouched and users migrate manifests at their own pace.

v1alpha1 and v1beta1 are schema-identical. The new
cmd/thv-operator/api/v1alpha1/ package defines only the root resource
types (MCPServer, MCPGroup, ...) as thin wrappers whose Spec and Status
fields reference the canonical types from v1beta1. controller-gen walks
field types when building the OpenAPI schema, so both versions resolve
to the same schema without any duplication of the actual model — I
verified empirically that all 12 CRDs produce structurally identical
schemas (modulo the legitimately-different root descriptions).

The upgrade is orchestrated through the `served` and `storage` flags
on each version entry: the new CRDs list both versions as served, mark
v1beta1 as storage, and mark v1alpha1 as deprecated with a warning.
No conversion webhook is configured, which defaults to strategy: None
— safe because the schemas are identical. Kubernetes swaps the
apiVersion string when serving an object at a different version than
it was stored at. Users can upgrade the CRD chart without deleting
anything, keep reading/writing at v1alpha1 indefinitely, and migrate
to v1beta1 by re-applying manifests. Once status.storedVersions no
longer contains v1alpha1, a future release can drop the v1alpha1
entry and remove the wrapper package.

What changed:

- Mechanical rename from v1alpha1 to v1beta1 across all Go imports,
  YAML apiVersion strings, Helm deploy manifests, chainsaw fixtures,
  examples, docs, and generated artifacts.
- New cmd/thv-operator/api/v1alpha1/ package: 12 root types + 12 list
  types as thin wrappers over v1beta1 Spec/Status, plus scheme
  registration. Each root type carries a +kubebuilder:d... (continued)

1559 of 3423 new or added lines in 53 files covered. (45.54%)

58479 of 88437 relevant lines covered (66.13%)

62.42 hits per line