Operator release notes

The PhoenixAI operator deploys and manages PhoenixAI clusters on Kubernetes. Each release is published on GitHub, with the notes below.

PhoenixAI Operator v2.0.0

Release date: September 9, 2026 · GitHub release

The first release under the PhoenixAI name, previously CelerData. This is a breaking major release: the CRD group, the kinds, the chart names and the Helm values have all been renamed, and existing clusters have to be migrated. There is no in-place helm upgrade from v1.11.x.

It is also the release that adds the PhoenixAI Anywhere console, and the release in which the operator manages elastic (shared-data) clusters only.

Breaking changes

Everything CelerData-branded is now PhoenixAI-branded

	v1.11.x (CelerData)	v2.0.0 (PhoenixAI)
API group	celerdata.com/v1	phoenixdata.ai/v1
Kinds	CelerDataCluster / CelerDataWarehouse	PhoenixAICluster / PhoenixAIWarehouse
Short names	cdc / cdw	pac / paw
CR spec fields	celerDataFeSpec, celerDataCnSpec, …	phoenixAIFeSpec, phoenixAICnSpec, …
Helm chart	kube-celerdata (subchart celerdata)	kube-anywhere (subcharts operator, phoenixai, anywhere)
Helm values keys	celerDataOperator, celerData*Spec	phoenixAIOperator, phoenixAI*Spec
Owner / hash labels	app.celerdata.…	app.phoenixai.…
Images	…/celerdata/operator, …/celerdata/{fe,cn}-ubuntu	us-west1-docker.pkg.dev/phoenix-ai-images/enterprise/…

There is no in-place upgrade path. Existing celerdata.com/v1 CRs, and existing kube-celerdata Helm releases, must be migrated with the converter and the runbook shipped with this release — Migrating from the open-source StarRocks operator to PhoenixAI, which covers CelerData-era sources too and detects them automatically. Migrating to v2.0.0 below outlines what that involves.

Your data and cluster identity are preserved: the StatefulSets are recreated over the same PVCs, and the pods come back with the same FQDNs and the same node IDs. There is a short outage while the pods are recreated.

Coming from the community StarRocks operator: v2.0.0's CR/CRD schema baseline is community v1.11.5. Upgrade the community operator to v1.11.5 first, confirm the cluster is healthy, then follow the same migration guide.

Elastic (shared-data) clusters only

v2.0.0 manages FE + CN clusters. The BE surface is gone from the CRD, the Helm charts, the migration converter and the documentation:

• spec.phoenixAIBeSpec is not in the CRD schema, so kubectl apply of a CR carrying it is rejected outright (strict decoding error: unknown field "spec.phoenixAIBeSpec");
• helm template/install fails with an explanatory error if BE values are present;
• the migration converter refuses a shared-nothing source rather than converting it silently.

A classic (shared-nothing) cluster therefore cannot be migrated to v2.0.0, and the Anywhere console operates elastic clusters only. run_mode = shared_data in fe.conf is what makes a cluster elastic, and it cannot be changed after the cluster is created.

New

• PhoenixAI Anywhere console. A web console for operating clusters: inventory and topology, SQL, query history and profiles, audit-log search, health checks, support bundles, snapshot and restore, and usage metering. It installs from the same chart, opt-in with anywhere.enabled=true, and needs object storage of its own plus a Prometheus to fill its monitoring views. See the console tour and Install with Helm.
• One chart installs everything. kube-anywhere deploys the operator, a PhoenixAI cluster and (optionally) the console in a single helm install. Its three subcharts are also published standalone, so you can run the operator, the cluster and the console as separate releases.
• Read-only operator API. The operator serves a gRPC API the console reads for cluster inventory, status and resource trees. It is on by default (operator.phoenixAIOperator.enableApiServer: true) and exposed as the kube-anywhere-operator-api Service on port 9090. Every read is served from the operator's informer cache, so console polling does not add load to the Kubernetes API server.
• PVC volume expansion. The operator can grow FE / CN (and warehouse CN) volumes in place, without restarting pods, by pre-creating and expanding the PVCs the StatefulSet adopts. On by default in this release (operator.phoenixAIOperator.enablePVCExpansion); requires a StorageClass with allowVolumeExpansion: true. Shrinking a volume and changing its StorageClass are refused with an explicit reason on the CR status. See Expand Persistent Volume.
• Automatic PodDisruptionBudgets. The operator creates one PDB per component — FE, CN, FE-proxy and each warehouse's CN — with maxUnavailable: 1, so kubectl drain, the cluster autoscaler and managed node-group upgrades can never evict two replicas of the same component at once. On by default (operator.phoenixAIOperator.enablePodDisruptionBudget). A PDB you created yourself with the same name is never overwritten, and turning the switch off does not delete PDBs that already exist. See Node maintenance and PDB.
• Migration converter. migrate-from-starrocks converts open-source StarRocks and CelerData-era manifests to the PhoenixAI form: cr mode for CR YAML (multi-document files supported), values mode for Helm values, and operator mode for the released operator.yaml. Data-plane image references are never rewritten. Binaries for Linux, macOS and Windows are attached to this release.

Changed defaults

Worth reading before you install, and before you migrate — the migration converter pins the ones that would otherwise change your cluster's behaviour, so a migrated cluster keeps its old values.

Value	v2.0.0 default	Note
enablePVCExpansion, enablePVCExpansionRBAC	on	adds cluster-scoped RBAC for StorageClasses
enablePodDisruptionBudget	on
enableApiServer	on	the console shows no clusters without it
waitForFullRollout	on	the release reports ready only once the cluster has rolled out
runAsNonRoot	on	FE/CN containers run as uid 1000
FE metadata storage	PVC (storageSpec.name: fe)	losing FE metadata loses the cluster, so the ephemeral alternative is now opt-in
Time zone	UTC	set phoenixai.phoenixAICluster.timeZone to keep another one

Fixed

• The FE/CN log volumes and the CN spill volume now inherit storageClassName from storageSpec.storageClassName when no volume-specific class is set, which is what values.yaml documented all along. Previously they silently fell back to the cluster's default StorageClass. This applies to newly created StatefulSets: a StatefulSet's volume claim templates are immutable, so an existing cluster keeps the volumes it has.
• run_mode in fe.conf is read case-insensitively and with surrounding whitespace ignored, so SHARED_DATA and shared_data mean the same thing. Previously writing it in upper case left you with a cluster that ran as elastic but got no compute nodes and no warehouses, because the operator did not recognise the value. An unquoted numeric run_mode no longer takes the operator down either.
• The console no longer counts a broken node as a healthy one. A pod that is crash-looping, stuck pulling its image, still starting up or being deleted now shows the same status the STATUS column of kubectl get pods shows — CrashLoopBackOff, ImagePullBackOff, NotReady, Init:0/2, Terminating — and Running only when every container in it is ready. Previously such a pod could appear as Running, so a cluster's node count looked right while a node was in fact down.
• Installing your first warehouse no longer requires restarting the operator, as long as you install with Helm: the warehouse CRD now ships with the operator chart, so it is already present when the operator starts. Previously the first warehouse created after the operator was silently never built — no pods, no events, no error — until someone restarted the operator. (Installing with kubectl still applies the warehouse CRD separately, so the restart is still needed on that path. If the CRD really is missing, the operator now says so in its log rather than staying quiet.)
• The migration converter no longer fails on an input file that ends with a trailing --- document separator.

Migrating to v2.0.0

The full procedure, with copy-pasteable commands for both paths, a verification section, warehouses dnd a rollback, is in Migrating from the open-source StarRocks operator to PhoenixAI. It applies to CelerData-era sources as well. What it involves:

Check two things first — either one stops the migration.

• A BE StatefulSet means the cluster is shared-nothing, and v2.0.0 cannot manage it.
• The FE/CN StatefulSets must keep persistentVolumeClaimRetentionPolicy.whenDeleted: Retain, the default. The whole migration rests on the PVCs outliving the StatefulSets.

Coming from the community operator, upgrade it to v1.11.5 first — that is v2.0.0's schema baseline — and confirm the cluster is healthy before going further.

Then convert and hand the cluster over. The migrate-from-starrocks binary attached to this release does the renaming; you choose the path that matches how the cluster was installed:

	Path A — kubectl / CR	Path B — Helm
Source	a StarRocksCluster / CelerDataCluster CR	a kube-starrocks / kube-celerdata release
Converter mode	cr (plus operator for the operator manifest)	values
Install	kubectl create the CRDs, apply the operator, apply the converted CR	helm install kube-anywhere with the converted values — one combined release, or separate operator and cluster releases

On both paths the PhoenixAI operator goes in before any downtime. Downtime starts when you stop the old operator and delete the old StatefulSets; it ends when the new ones have recreated the pods over the same volumes.

What this does and does not touch. Only the operator changes. The FE/CN images, the object storage and the cluster's own metadata are untouched, and the converter never rewrites a data-plane image reference. The cluster name must stay identical — every resource name derives from it, and that is what makes the new StatefulSets adopt the existing PVCs. So your data and cluster identity survive: same PVCs, same FQDNs, same node IDs and the same ClusterId.

The hard constraint is that the StatefulSets are deleted and recreated rather than updated, so there is a short outage while the pods come back.

One cosmetic side effect: PVCs carried over keep the previous operator's owner-reference label, because Kubernetes only stamps that label when it creates a PVC, never when a StatefulSet adopts one. Relabelling them is optional and only matters to your own tooling — the operator finds them either way. If you do relabel, keep the old label in place so a rollback still works.

Verify with the guide's Verify section (SHOW FRONTENDS / SHOW COMPUTE NODES all Alive, the node IDs unchanged, SHOW WAREHOUSES intact), and retire the old operator and its CRDs only after that passes. Warehouses have their own short section, and there is a documented rollback for both paths.