BKE

The Passage Plan

Every upgrade, laid out before it runs.

Before a ship leaves harbour, the navigator draws the passage plan and the master approves it: every leg, every hazard, before the vessel moves. BKE treats an upgrade the same way.

apply.sh without --commit reports what an upgrade would change in each component's configuration, and changes nothing. The Passage Plan is that report in the console — every diff, in full and in colour — for anyone in your organisation to read before anyone commits to it.

The Passage Plan in the documentation → What happens to your edits →
The Passage Plan in the Mamluk console for a Longhorn upgrade, in the unified view. Under the heading What BKE changed, six added lines set networkPolicies.restrictInternalTraffic to false, with a comment explaining that BKE keeps the behaviour of the version the cluster is on. Under What changes in your file, the same six lines are added to /etc/bke/values/longhorn.yaml. Unchanged lines are folded. The Passage Plan in the Mamluk console for a Longhorn upgrade, in the unified view. Under the heading What BKE changed, six added lines set networkPolicies.restrictInternalTraffic to false, with a comment explaining that BKE keeps the behaviour of the version the cluster is on. Under What changes in your file, the same six lines are added to /etc/bke/values/longhorn.yaml. Unchanged lines are folded.
An upgrade, in the unified view. What BKE changed in its own default, and what that means for your file, are shown separately. Here the customer's own Longhorn settings are left exactly as they were; only BKE's new setting is added.

What it shows

Three questions, answered separately.

Every component's configuration is a values file you own and may edit. When an upgrade would change one, the report — and the Passage Plan — separate what we changed from what it means for you.

what BKE changed

Our change, on its own.

Our default for the version you are on, against our default for the version you are moving to. It is the same for every cluster with your configuration, which makes it the diff to quote in a support request.

what changes in your file

Exactly what will be written.

Your file as it is now, against the file --commit will write and hand to Helm. Your edits stand. Where you and BKE changed the same setting differently, the run stops and shows you both values.

what the cluster is running

Drift, caught first.

If someone changed a release by hand, your file no longer describes the cluster. BKE compares the two, shows only that difference, and goes no further until it is settled.

Side by side

Read it the way a reviewer reads a change.

The same diffs, unified or side by side, with line numbers on both sides and the unchanged stretches folded away until you ask for them.

The Passage Plan in the side-by-side view, headed Your file is not what the cluster is running, for Kong. The left column shows what the cluster is running according to helm get values, the right column shows /etc/bke/values/kong.yaml. Four lines differ: averageUtilization 70 against 90, nginx_worker_connections 4096 against 2048, and the CPU and memory limits 2500m and 4G against 1500m and 3G. The Passage Plan in the side-by-side view, headed Your file is not what the cluster is running, for Kong. The left column shows what the cluster is running according to helm get values, the right column shows /etc/bke/values/kong.yaml. Four lines differ: averageUtilization 70 against 90, nginx_worker_connections 4096 against 2048, and the CPU and memory limits 2500m and 4G against 1500m and 3G.
Drift, side by side. Someone raised Kong's limits on the cluster by hand, and the values file was never updated. BKE stops the upgrade and shows exactly where the two disagree.

Why the console

The person who approves a change rarely has a shell on the node.

For the whole organisation.

The report ends with a link. Any member of your organisation, signed in to the console, can open it — the engineer who ran it, the architect who reviews it, the change board that approves it.

Nothing is summarised away.

The terminal still prints every diff, as before, and counts the lines of one too large to print. The Passage Plan shows that one in full as well.

It decides nothing.

The page is read-only, and opening it is optional. What it shows is applied only when apply.sh --commit is run on the node.

Private by construction

A values file can hold more than settings. The Passage Plan is built for that.

encrypted, with a key we do not keep

The diffs are encrypted before they are stored, under a fresh key for every report. The key is printed on your node and carried in the link after the #, which a browser does not send to any server. The console decrypts the Passage Plan in your browser.

members only

The link alone opens nothing. The reader must be signed in to the console as a member of the organisation that holds the licence, and the key must match.

for an hour, then gone

The report states when the link stops working, an hour after it was produced. A new one is a single command away: apply.sh without --commit changes nothing on the cluster.

only the diffs

What is kept is the diffs the report showed — not your configuration, not your cluster's state — and it is kept nowhere but there.

An upgrade you have read before it runs.

The Passage Plan is part of every BKE licence, including the 14-day trial. There is no edition that has it and one that does not.

Installing components → Upgrading → What's included →