v2.0.0

PhoenixAI Operator v2.0.0

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 rel...

v1.11.7

What's Changed

• [Chore] Update repo URLs after the rename to phoenixai-kubernetes-operator by @yandongxiao in #3
• [Chore] Update contents for scripts dir by @yandongxiao in #4
• [Chore] prepare things for v1.11.7 by @yandongxiao in #6

Full Changelog: v1.11.6...v1.11.7

v1.11.6

Note

Because the project has been renamed to phoenixai-kubernetes-operator, you need to update the helm repo, like this:

  helm repo remove celerdata
  helm repo add celerdata https://celerdata.github.io/phoenixai-kubernetes-operator
  helm repo update celerdata

What's Changed

• Support externalTrafficPolicy for service component. If you want the externalTrafficPolicy field to take effect, you can just modify the related service annotation app.celerdata.components/hash to another value.

Full Changelog: v1.11.5...v1.11.6

v1.11.5 🌈

Note

Because the project has been renamed to phoenixai-kubernetes-operator, you need to update the helm repo, like this:

  helm repo remove celerdata
  helm repo add celerdata https://celerdata.github.io/phoenixai-kubernetes-operator
  helm repo update celerdata

v1.11.4

[Feature] Add YAML files and helm charts

Signed-off-by: yandongxiao <dxyan06@gmail.com>