Settings changed by hand

The installer generates the platform's own cluster objects — its ingress among them — from the platform configuration, the Secret stackship-install-config in stackship-system. A field someone changes directly in the cluster, with kubectl edit for example, no longer matches what the running release installs: that is platform drift.

The platform looks for it in two places:

• A scan runs the running release's installer as a dry run: two minutes after the Lifecycle module starts, every six hours after that, after every successful rollout, and when you choose Check now. It never runs while a rollout executes or is paused; a scan that is due then waits, and starts within a minute of the rollout ending.
• The platform step of a release rollout stops before it overwrites a field changed by hand, and pauses the rollout.

A change is either made permanent in the configuration — adopted — or put back by the next release rollout.

See the last scan

Open Settings → Lifecycle Manager, the After upgrading tab, and its Platform drift section. It shows the result of the last scan — No drift, Changed by hand, Scan failed or Unavailable, with the reason, or Not scanned yet — the release it compared against, when it ran and why, and when the next one is due. While a new scan runs, the previous result stays on screen with a line saying a new one is under way.

Check now starts a scan and needs lifecycle/plan. It is refused while a scan is already running, or while a rollout executes — a rollout checks the platform itself.

Unavailable usually means the running operator is too old to scan, or the running release has no installer.

Decide what to do with each change

When the scan found changes, each is listed with its Object, Field and Changed by — the tool or controller the cluster recorded. Show values shows the Release value next to the Value in the cluster. The last column, What you can do, offers Adopt into config or explains why the change Cannot be adopted.

Whatever you leave as it is makes the next release rollout pause at its platform step.

Adopt a change into the configuration

Adopting writes the value from the cluster into the platform configuration, so the next release rollout keeps it instead of reverting it. It needs lifecycle/execute.

1. Choose Adopt into config on the change. One button covers every field the same setting explains.
2. Read the dialog. It shows the Setting and its new Value; under Objects the installer will render differently, every other object that changes as a result, before and after — a new portal domain also changes allowed origins, for example; and under Also read by, what else reads the setting and when it follows: at the next release rollout, at the next upgrade of a third-party chart, or only at install. Anything marked Delayed keeps the old value until then.
3. Tick I understand the platform configuration changes to the value from the cluster and choose Adopt into config.

The change is recorded in the activity log, and a new scan starts to confirm the drift is gone. Adopting changes the configuration only; the objects follow as the dialog said.

The adoption is refused, and you review again, when a newer scan exists, the value in the cluster or the configuration has changed since the scan, or a rollout is executing.

When a change cannot be adopted

The last column then says why:

• It is not a platform configuration setting. The next release rollout pauses and offers to revert it.
• The value alone does not explain the change — other differences remain.
• The objects disagree on the value, so there is no single value to adopt.
• The certificate issuer is managed by the installer. Only an external issuer can be adopted.
• Part of the platform reads the setting only at install, so changing it needs a reinstall.

When a release rollout pauses on it

A release rollout that finds settings changed by hand changes nothing and pauses. Its page shows Settings changed by hand in the cluster: each object, field and who changed it, with the cluster's own message under Show details. You have two ways on, both with lifecycle/execute:

• Keep the change, or undo it, then Resume. To keep it, adopt it as above, or write it into stackship-install-config yourself; to drop it, undo it in the cluster. Then choose Resume: the step runs again against the cluster as it is then.
• Revert changes puts the release's values back and the rollout continues. What was changed by hand in those fields is lost, so you tick I understand these manual changes will be overwritten and choose Overwrite changes. If the changes in the cluster move while you are deciding, the dialog shows them as they are now and asks you to review again. The revert is recorded on the rollout and in the activity log.

Revert changes is unavailable, with the reason shown, when the running operator is too old to overwrite changes made by hand. A later plain Resume never overwrites anything.