Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions chart/skywalking-swck/Chart.yaml
Original file line number Diff line number Diff line change
Expand Up @@ -22,8 +22,8 @@ description: SkyWalking Cloud on Kubernetes -- the SkyWalking operator and its c
home: https://github.com/apache/skywalking-swck
icon: https://raw.githubusercontent.com/apache/skywalking-kubernetes/master/logo/sw-logo-for-chart.jpg
# The chart is released from, and versioned with, the operator it deploys.
version: 0.11.0
appVersion: "0.11.0"
version: 0.12.0
appVersion: "0.12.0"
# The floor the repository documents and the e2e suite runs against
# (test/e2e/kind.yaml pins kindest/node:v1.21.10).
kubeVersion: ">=1.21.0-0"
Expand Down
57 changes: 57 additions & 0 deletions docs/en/changes/changes-0.11.0.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,57 @@
## 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 `secretKeyRef`s 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.
Loading
Loading