Upgrade to SkyWalking 11.0.0, Horizon UI 1.0.0 and BanyanDB 0.11.0 - #194
Open
wu-sheng wants to merge 4 commits into
Open
Upgrade to SkyWalking 11.0.0, Horizon UI 1.0.0 and BanyanDB 0.11.0#194wu-sheng wants to merge 4 commits into
wu-sheng wants to merge 4 commits into
Conversation
OAP 11.0.0, Horizon UI 1.0.0 and BanyanDB 0.11.0 are all released. OAP 11 accepts BanyanDB server API 0.11 only (SW_STORAGE_BANYANDB_COMPATIBLE_SERVER_API_VERSIONS), so the three move together -- OAP 11 against BanyanDB 0.10.x refuses to start with an exact-string version check, no lenient fallback. Chart version goes to 5.0.0: OAP 11 drops the bundled web UI and serves /status/* and /debugging/* on the admin port only, so oap.ports.admin is no longer optional. Horizon 1.0.0 config surface: - ui.config.templates.mode -- new upstream setting, and the one that decides whether a deployment works at all. The default `live` reads dashboard templates from OAP 11's /ui-management/templates* REST API; OAP 10 has no such surface, so it needs `readonly`, which renders the templates bundled in the image. - server.publicUrl is derived from the first ui.ingress.hosts entry when an ingress is enabled (https when ui.ingress.tls is set). Horizon builds SSO callbacks and its OAuth issuer from it; left blank it derives the URL per-request, which is wrong behind a proxy that rewrites Host. An explicit ui.config.server.publicUrl still wins. - server.trustProxy is surfaced with the boot constraint documented: it takes a hop count or an address/CIDR, and `true` is refused because it would let any caller choose the address written to the login audit. - ui.extraVolumes / ui.extraVolumeMounts, because two 1.0.0 settings take a filesystem path rather than a value: auth.tokensFile (API tokens for scripts, CI and MCP clients) and sourceMaps.bootMountDir (durable .map files; without a volume, runtime uploads are in-memory only and lost on pod restart). Docs corrections against the 1.0.0 tree: horizon.example.yaml no longer exists -- the image's /app/horizon.yaml is itself the fully env-tokenized example -- and GHCR tags releases as x.y.z rather than vX.Y.Z. E2E now runs the released OAP and Horizon images so CI validates exactly what the README tells users to install. BanyanDB moves to a GHCR pin of the v0.11.0 commit, replacing a pin from 2026-08-03 that predates 0.11 and cannot satisfy OAP 11's version check. It stays on GHCR because 0.11.0's Docker Hub publish path arrived in apache/skywalking-banyandb#1315, which landed after the v0.11.0 tag and has never been dispatched for it, so no release image exists yet.
…emoval Horizon 1.0.0 runs against OAP 10.4.0 as well as OAP 11.x, so the chart has no reason to treat 10.x as a degraded path -- pin horizon-1.0.0 whichever OAP release you run, and for 10.x add templates.mode: readonly. That is the whole difference. Drop the install-time warning that sniffed oap.image.tag for a "10." prefix. Horizon probes for the capabilities it consumes rather than comparing version numbers, so the chart guessing from an image tag added a failure mode of its own (a tag like 10.4.0-java17 or a digest pin reads differently) to restate something NOTES.txt can just say unconditionally. Document that booster UI is not supported, with the reason: OAP 11 deleted apm-webapp and the skywalking-ui submodule along with the docker.ui target, so the last booster image on apache/skywalking-ui is 10.4.0 and only horizon-* tags are published now. The OAP-side surfaces it depended on went with it -- the ui-initialized-templates seed files, menu storage, the UIConfigurationManagement GraphQL mutations, and SW_ENABLE_UPDATE_UI_TEMPLATE. That last point makes the oap.config example for ui-initialized-templates dead on OAP 11; replace it with a note saying so, since silently leaving it would have operators writing config that is read by nothing.
values.yaml is read by someone deciding what to set, not by someone auditing what changed between releases. Several comments added in this branch narrated the latter: what OAP 11 deleted, what is "no longer" mirrored on 12800, what does not exist "any more". That belongs in the commit and release notes, which is where a reader looking for it will go. This repo has no CHANGES file, so history is the changelog. Concretely: - Drop the `ui-initialized-templates` example from oap.config, and the note explaining its removal along with it. OAP 11 deleted the on-disk dashboard seed files and UITemplateInitializer, so the key is read by nothing; Horizon ships its own dashboard library and manages templates over the admin REST port. An example that does nothing is worse than no example, and an obituary for it is not configuration guidance. - oap.ports.admin now says what the port serves and that it is required, rather than which modules OAP 11 turned on by default and what moved off 12800. - ui.image.tag says the tag must be a `horizon-*` one and points at the README for the booster removal, instead of restating the removal inline. - ui.securityContext drops the aside that /app/bundled_templates is baked in rather than mounted -- true, but it corrects a misreading nobody arrives with. - ui.config.templates.mode keeps the operator guidance (set readonly on OAP 10) and drops the account of OAP 11 retiring the legacy GraphQL surface.
wu-sheng
force-pushed
the
upgrade-skywalking-11.0.0-horizon-1.0.0
branch
from
August 29, 2026 13:24
6ee625b to
b7d8e31
Compare
…d config
Horizon 1.0.0's image ships a fully env-tokenized /app/horizon.yaml -- every
field is a ${HORIZON_*:default} placeholder -- and the chart was mounting a
ConfigMap of literals over it. That is not merely redundant. Horizon expands
${...} over the raw file TEXT before parsing it (apps/bff/src/config/loader.ts),
so a field written as a literal makes its HORIZON_* env var silently inert, and
a field the file omits falls back to a schema default that consults process.env
for only ~18 of the image's ~65 vars. The chart was therefore disabling most of
the image's configuration surface, including every HORIZON_OAP_*, HORIZON_AUTH_*,
HORIZON_RBAC_*, HORIZON_SESSION_* and HORIZON_PERFORMANCE var, with nothing
telling the operator which ones had stopped working.
Of the 12 fields the ConfigMap wrote, only two carried anything the image cannot
know. So:
- ui.config defaults to {}. server.host, oap.timeoutMs, auth.backend,
rbac.enabled, session.* and templates.mode were all byte-identical to the
image's own defaults; upstream owns them now.
- The chart writes only what it computes: the in-cluster OAP query/admin URLs,
zipkinUrl when that port is exposed, publicUrl when an ingress is enabled, and
server.port from ui.service.internalPort so the BFF binds the port the
container actually exposes.
- Those go in as TOKENS, not literals --
`queryUrl: ${HORIZON_OAP_QUERY_URL:http://<release>-oap:12800}` -- so the
in-cluster value is the default and env still overrides it. The mount stays
unconditional: gating it on ui.config being non-empty would mean a one-field
override (templates.mode: readonly, which the README tells OAP 10 users to
set) mounts a partial file whose absent oap block reverts to 127.0.0.1.
Also correct a claim this turned up, in four places: the BFF does NOT refuse to
start without users. It boots, logs an error, serves the login page, and answers
/api/auth/health with 200 -- which is the chart's own readinessProbe -- so the
pod reports Ready and nobody can log in. That is worse than the CrashLoopBackOff
the docs promised, and the docs now say so.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
OAP 11.0.0, Horizon UI 1.0.0 and BanyanDB 0.11.0 are all released. This upgrades the chart to them.
OAP 11 accepts BanyanDB server API
0.11only (SW_STORAGE_BANYANDB_COMPATIBLE_SERVER_API_VERSIONS), which maps to BanyanDB release0.11.x— so the three have to move together. OAP 11 against BanyanDB 0.10.x refuses to start withIncompatible BanyanDB server API version.Chart version goes to 5.0.0: OAP 11 drops the bundled web UI and serves
/status/*and/debugging/*on the admin port exclusively, sooap.ports.adminis no longer optional.Horizon UI 1.0.0 is the UI for every supported OAP
Horizon 1.0.0 runs against OAP 10.4.0 as well as OAP 11.x, so the chart does not treat 10.x as a degraded path. Pin
ui.image.tag=horizon-1.0.0whichever OAP release you run; against 10.x also setui.config.templates.mode: readonly. That is the whole difference.Booster UI is not supported
Documented in the README, with the reason. OAP 11 removed the bundled UI outright:
apm-webapp/and theskywalking-uisubmodule trackingapache/skywalking-booster-uiwere deleted along with thedocker.uiMaven target and the image build. So the last booster image onapache/skywalking-uiis10.4.0— there is no11.xtag and there will not be one, and onlyhorizon-*tags are published going forward.The OAP-side surfaces booster depended on went with it: the
ui-initialized-templatesseed files, the sidebar menu storage, theUIConfigurationManagementGraphQL mutations, andSW_ENABLE_UPDATE_UI_TEMPLATE. That makes theoap.configexample forui-initialized-templatesdead on OAP 11 — it is now a note saying so, rather than an example that has operators writing config nothing reads.New config surface
ui.config.templates.mode—live(default) reads dashboard templates from OAP 11's/ui-management/templates*admin REST API;readonlyrenders the templates bundled in the image.readonlyis how Horizon 1.0.0 runs against OAP 10.4.0.server.publicUrl— derived from the firstui.ingress.hostsentry when an ingress is enabled (httpswhenui.ingress.tlsis set). Horizon builds SSO callbacks and its OAuth issuer from it; left blank it derives the URL per-request, which is wrong behind a proxy that rewritesHost. An explicitui.config.server.publicUrlstill wins.server.trustProxy— surfaced with the boot constraint documented: it takes a hop count or an address/CIDR, andtrueis refused at boot because it would let any caller choose the address written to the login audit.ui.extraVolumes/ui.extraVolumeMounts— two 1.0.0 settings take a filesystem path rather than a value:auth.tokensFile(API tokens for scripts, CI and MCP clients) andsourceMaps.bootMountDir(durable.mapfiles; without a volume, runtime uploads are in-memory only and lost on pod restart).Docs corrections
Checked against the
v1.0.0tree:horizon.example.yamlno longer exists — the image's/app/horizon.yamlis itself the fully env-tokenized example.x.y.z, notvX.Y.Z(ghcr.io/apache/skywalking-horizon-ui:1.0.0resolves;v1.0.0404s)./app/bundled_templatesis baked into the image at build time; it is not a mount point.E2E
Now runs the released OAP and Horizon images so CI validates exactly what the README tells users to install.
BanyanDB moves to a GHCR pin of the v0.11.0 commit (
3b83e18, "feat: advertise BanyanDB API version 0.11"), replacing the previous pin3692170from 2026-08-03 — that one predates 0.11 and cannot satisfy OAP 11's exact-version check, so CI would not have been testing a valid pairing.It stays on GHCR rather than moving to a release tag because 0.11.0's Docker Hub publish has not happened: the
publish-dockerworkflow's Docker Hub path arrived in apache/skywalking-banyandb#1315, which landed onmainafter thev0.11.0tag and has never been dispatched for it.docker.io/apache/skywalking-banyandb:0.11.0404s today. There is aTODOintest/e2e/envto switch once it exists.Verification
helm lintclean.elasticsearch,postgresqlandbanyandbstorage types, withui.enabled=false, and withsatellite.enabled=true.publicUrlderivation checked for ingress+TLS, ingress without TLS, and explicit override.NOTES.txtrenders the same guidance for every OAP tag — no image-tag sniffing.Base
Rebased onto current master, which already pins
skywalking-banyandb-helmat0.7.0-rc1(#193). That pin is untouched here.No change needed
chart/operatorandchart/adapterstay at SWCK 0.10.0 — it already exposes port 17128 and supports Horizon (ui_webhook.go:65), and SWCK has no newer release.