0.11.0

Bugs

  • Add tools/releasing/preflight.sh, which checks everything a release needs before release.sh does anything irreversible: the tools, the signing key and whether it is in the published KEYS file, gh authentication, the dist URLs, that the version agrees between Chart.yaml and the changelog and that its tag is free, that no abandoned candidate is sitting in dist/dev, and that the tree is clean with the generated chart files in sync. release.sh runs it as its first step, before asking about the signing key, and takes the resolved key from it rather than detecting one itself. It reports every problem rather than stopping at the first, and is explicit about the three things it cannot check from a developer machine.
  • Let tools/releasing/release.sh run when the tree already carries the release version. It committed the version bump with a plain git commit, which exits non-zero with nothing staged, and the script runs under set -e – so a release cut the documented way, with Chart.yaml already updated and the kustomize image tags already set by the same function, died at “nothing to commit, working tree clean” before tagging or building anything. Both release commits allow an empty diff now, which also keeps the regeneration --amend pointed at the script’s own commit rather than at whatever master happened to be.
  • Build genuinely multi-architecture images, again. The previous fix declared ARG TARGETARCH=amd64 in each Dockerfile, and giving a predefined platform argument a default makes BuildKit use that default instead of the target’s architecture – so TARGETARCH read amd64 even when building for linux/arm64, the builder stage ran once, and the amd64 binary was copied into the arm64 manifest. The publish workflow’s own ELF check caught it on the first run that was ever able to start. The argument is declared with no default now, and the shell falls back to the native architecture for a plain docker build, which was also producing amd64 binaries on an arm64 host.

Features

  • Release the skywalking-swck Helm chart from this repository. One chart installs the operator and, behind a values flag, the custom metrics adapter. The CRDs, the operator’s ClusterRole and the admission webhook configurations it ships are generated from the operator sources by make chart-manifests, and CI fails on any drift.

Bugs

  • Stop reconciling a UI whose kind is no longer supported. Narrowing the CRD enum to horizon only rejects new resources – schema validation runs on admission, never on read – so a UI stored as kind: booster by an earlier operator survives the upgrade and still reconciles. With the templates now unconditionally Horizon’s, reconciling one rewrote a running Booster Deployment into a shape its image cannot serve and took the UI down on the first pass after upgrade. Such a resource is now left untouched, with a UnsupportedKind event saying what to do.
  • Stop applying an OAPServer Deployment when the Storage it names cannot be read. Every lookup error was logged and ignored, and the Deployment was applied anyway – without SW_STORAGE, targets, credentials or TLS volumes – so a Storage briefly deleted and recreated replaced a working OAP with one that never becomes ready. The reconcile now leaves the running Deployment alone, emits a StorageUnresolved event and requeues.
  • Keep the storage TLS volume when an OAPServerConfig mounts static files. The overlay assigned over the pod’s volume and mount lists, and ApplyOverlay is an RFC 7386 merge patch under which an array replaces rather than merges – so the certificate volume disappeared and SW_STORAGE_BANYANDB_SSL_TRUST_CA_PATH pointed at nothing. The lists are merged by name now, and the mount is reconciled on every pass rather than skipped whenever the file content is unchanged, which had left it lost for good after any re-render.
  • Roll the OAP when its credential Secret is rotated. Environment variables taken from a Secret are resolved once, when the container starts, so moving credentials to secretKeyRef meant a rotation went unnoticed until something restarted the pod. The controller now watches Secrets and carries the referenced Secret’s resourceVersion in a pod-template annotation – an opaque token, not a digest of the credential.
  • Create certificate signing requests through certificates.k8s.io/v1. The v1beta1 API this used was removed in Kubernetes 1.22, so internal Elasticsearch TLS could not obtain a certificate on any cluster newer than that and the workload waited on a Secret nothing produced. The wait loop is also bounded now, and sleeps – it used to spin on Get with no delay and no limit.
  • Require SW_STORAGE to carry a value. The mandatory-storage check accepted an entry named SW_STORAGE with nothing behind it, which reaches the OAP as an empty selector and produces exactly the never-ready state the check exists to prevent.
  • Require a published GitHub release before publishing convenience binaries. Both the publish workflow and release-passed.sh tested only whether gh release view succeeded, and that resolves drafts – so a dispatch against a draft could put official version-tagged images on GHCR before the vote, and release-passed.sh mistook a draft for a finished release and never published it. Both now require isDraft: false and a publication time; the workflow rejects prereleases too.
  • Stop truncating rendered manifests at the first #. Every manifest was cut line-by-line at its first hash with no awareness of YAML quoting, so any value containing one – a password, an AI prompt, a URL fragment – was severed mid-string and the resulting manifest no longer parsed. Only whole-line comments are dropped now. This became reachable for user-supplied values with spec.env.
  • Deep-copy the new env and envFrom fields. zz_generated.deepcopy.go had not been regenerated, so those slices were shared with the objects controller-runtime’s cache hands out.
  • Render an OAPServer whose Storage cannot be read yet. spec.storage.name is now mandatory, but the operator fills in the resolved Storage only once it can read it, and the deployment template reached through the nil – so an OAPServer applied before its Storage failed to render at all rather than waiting for it.
  • Reference the Elasticsearch credentials from the Storage controller too. The OAPServer side stopped copying them out of the Secret; the Storage controller still did, putting the password into the resource and the Elasticsearch StatefulSet it renders.
  • Document BanyanDB storage: the endpoint format and its gRPC port, cluster targets, authentication, persistence, and the flags BanyanDB 0.11 renamed. See docs/en/setup/banyandb.md.
  • Pass BanyanDB credentials from a Storage’s security.user.secretName, as the Elasticsearch path already did.
  • Raise the OAP startup probe budget from 110 seconds to 10 minutes. SkyWalking 11 has no embedded storage, so every start installs a schema into BanyanDB or Elasticsearch – work that overran the old probe on a cold cluster, and being killed mid-schema turned a slow first boot into a crash loop.
  • Wire BanyanDB storage. The operator could only configure Elasticsearch, so an OAPServer on BanyanDB had to carry the storage environment by hand – and the variable it needed changed name between SkyWalking 9.x and 11.x. A Storage of type: banyandb now yields SW_STORAGE=banyandb and SW_STORAGE_BANYANDB_TARGETS. Without this, SWCK cannot deploy a working OAP at all across the supported range: SkyWalking removed H2 permanently in 10.2.0, so there is no fallback and an OAPServer with no storage never becomes ready.
  • Stop deriving the Horizon admin and Zipkin URLs. The OAP admin host arrived in 11.x, and on 10.x port 17128 is the AI-pipeline URI-recognition server, so a derived oap.adminUrl pointed Horizon at a live endpoint that was the wrong service; the OAPServer this operator deploys exposes no Zipkin port at all. Both are now emitted only when spec.OAPServerAdminAddress / spec.OAPServerZipkinAddress are set, matching what skywalking-helm does.
  • Fix the default image for kind: horizon UIs. It was apache/skywalking-horizon-ui:<version>, a Docker Hub repository that does not exist – Horizon releases share apache/skywalking-ui with the legacy Booster UI and are told apart by a horizon- tag prefix. Since horizon is the default kind, every UI created without an explicit image could never pull. Covered by a unit test; the samples and docs carried the same wrong name.
  • Build genuinely multi-architecture images. operator/Dockerfile, adapter/Dockerfile and build/images/Dockerfile.release hardcoded GOARCH=amd64 and -linux-amd64 while the publish workflow advertised linux/arm64, so apache/skywalking-swck:0.10.0 shipped an arm64 manifest holding x86-64 binaries and an arm64 node got exec format error. The release now builds a binary per architecture, and the publish workflow pulls every advertised platform back and checks the ELF machine type before the release completes.
  • Ship the eventexporter admission webhook in the chart, and drop the duplicate meventexporter.kb.io entry that the API server rejects. Both come out of generating the webhook configurations from the operator sources rather than hand-copying them.

Chores

  • Seed the e2e login from a Secret through UI.spec.envFrom, so the new envFrom surface is exercised against a real cluster rather than only unit-tested: if it did not reach the container there would be no user and oap-ui-agent’s login would fail.
  • Split the e2e suite by configuration path. Almost every case now runs the Horizon UI on HORIZON_* environment variables with no ConfigMap at all, and oap-ui-agent proves they arrive by logging in and reading the OAP hosts back through the BFF. Exactly one case, oap-ui-agent-oapserverconfig-oapserverdynamicconfig, takes the override path: the UI carries a whole horizon.yaml in spec.config while its OAPServerConfig overlays a static file on the OAP.
  • Configure the Horizon UI with environment variables instead of a generated file. Horizon’s image bakes a fully tokenised horizon.yaml, so every setting it has is reachable as HORIZON_* – but the operator mounted its own file over that one, which replaced every token and left the container with no env: at all, so no variable could reach any setting. UI.spec.env and UI.spec.envFrom now carry them, the operator sets only what it derives, and the ConfigMap is mounted only when spec.config supplies a whole file. A setting added in a future Horizon release works without an SWCK release.
  • Add envFrom to OAPServer and Satellite, which are configured entirely through environment variables and previously had no way to take one from a Secret.
  • Reference storage credentials instead of copying them. The operator read the Storage’s user secret and wrote the username and password in as literal env values, so they appeared in both the OAPServer and its Deployment for anyone with read access. They are now secretKeyRefs resolved by the kubelet. This also needed a template fix: the OAP deployment rendered only name/value and silently dropped valueFrom, so a secret reference could not have worked at all.
  • Wire BanyanDB TLS. security.tls with security.tlsSecretName mounts the CA at /skywalking/bydb-tls and sets SW_STORAGE_BANYANDB_SSL_TRUST_CA_PATH. Previously tls: true on a banyandb Storage was accepted, wired no TLS, and mounted the Elasticsearch keystore secret skywalking-storage, leaving the OAP pod waiting on a secret nothing creates; tlsSecretName is now required for that combination.
  • Add UI.spec.templatesMode, emitted as HORIZON_TEMPLATES_MODE. Left unset it follows the admin address: live reads OAP’s template store over the OAP admin host, so it is chosen only when spec.OAPServerAdminAddress is set, and readonly – which renders the templates bundled in the image – otherwise. Defaulting to live regardless would leave every UI probing 127.0.0.1:17128, failing Horizon’s ui-management preflight and blocking every layer-driven page, Traces most visibly. OAP 10.x needs readonly in any case: it manages templates over legacy query-port GraphQL and Horizon speaks only OAP 11’s REST protocol.
  • Stop maintaining a copy of Horizon’s configuration schema. The config the operator used to generate restated Horizon’s own defaults, and the copy had drifted: viewer was granted 6 of the 12 permissions Horizon gives that role, and the admin landing route was /admin/cluster, which Horizon has no route for – signing in as admin landed on “No route matches”. It also carried audit.file, setup and alarms, keys Horizon 1.0.0’s schema does not have and whose presence stops the BFF booting at all.
  • Refuse an OAPServer that has no storage. SkyWalking removed the embedded H2 permanently in 10.2.0, so no version this operator supports has one and there is nothing to fall back to: an OAPServer with nowhere to write starts, dials a BanyanDB on 127.0.0.1:17912 and never becomes ready. The webhook now says so at admission instead. Setting SW_STORAGE directly in spec.config still counts as having chosen a storage. Breaking: an OAPServer with neither spec.storage.name nor SW_STORAGE is rejected – it could never have worked.
  • Publish the operator image, the metrics adapter image and the Helm chart from the release publish workflow, triggered by publishing a GitHub release, instead of pushing tags by hand. Pushes to master keep publishing SHA-tagged snapshots to GHCR.
  • Add tools/releasing/release.sh and tools/releasing/release-passed.sh, automating the release either side of the vote.
  • Ship the Helm chart tarball as a signed, voted artifact on dist.apache.org, alongside the source and binary tarballs.
  • Support OAP 10.4.0 and later, with 11.0.0 recommended, matching skywalking-helm. An OAPServer below that is admitted with a warning rather than rejected.
  • Deploy only the Horizon UI. spec.kind on the UI resource now accepts horizon alone – apache/skywalking removed the legacy Booster UI in 11.0.0 and no longer builds an image for it. Breaking: a UI with kind: booster is rejected, with a message saying what to use instead.
  • Default OAPServerConfig and OAPServerDynamicConfig to version 11.0.0, was 9.5.0. These match an OAPServer by exact version string, so a config that omits version previously only attached to an OAP explicitly pinned at 9.5.0. Behaviour change: set spec.version explicitly if you run an older OAP.
  • Verify the Horizon UI over its own API rather than a GraphQL proxy it does not have: every UI case asserts the auth backend at the public /api/auth/health, and oap-ui-agent logs in with a seeded user and calls an RBAC-protected route. Document that Horizon ships with no users, so a UI refuses every login until one is seeded through HORIZON_AUTH_LOCAL_USERS.
  • Move the e2e suite to the current SkyWalking stack: OAP 11.0.0, Horizon UI 1.0.0 and BanyanDB 0.11.0, which have to move together because OAP 11.0.0 accepts BanyanDB server API 0.11 only and Horizon 1.0.0’s admin host is an OAP 11 addition. The UI cases previously deployed the legacy Booster UI, which apache/skywalking no longer builds an image for.
  • Pin every image the e2e suite deploys in test/e2e/env, substituted with envsubst, replacing apache/skywalking-banyandb:latest and centralising nine images that were spread across fifteen manifests.
  • Install the operator with the Helm chart in ten of the twelve e2e cases, and add a case that tests the chart’s own lifecycle: installing the packaged tarball, CRDs, webhook CA injection, agent injection, HPA metrics, upgrade in both directions, and uninstall without taking the CRDs with it. test/e2e/oap-ui-agent stays on kustomize so that install path remains covered.
  • Split hack/ by purpose: developer and build tooling moved to tools/, test tooling to test/tools/.
  • Restructure the documentation into docs/en/{concepts-and-designs,setup,examples,guides,changes}, following the layout of apache/skywalking, and move the changelog from CHANGES.md into docs/en/changes/.
  • Bump go.opentelemetry.io/otel to v1.44.0 to fix CVE-2026-41178.
  • Bump golang.org/x/net to v0.55.0, golang.org/x/crypto to v0.53.0 and golang.org/x/sys to v0.46.0.
  • Bump software.sslmate.com/src/go-pkcs12, github.com/sirupsen/logrus, github.com/go-logr/logr, google.golang.org/grpc, golang.org/x/text and the Kubernetes dependencies.
  • Bump the actions-deps group across the repository.