Stand configuration

The configuration is the set of settings the applications on a stand run with: the version of each application, the addresses of external systems, enabled and disabled features, limits and other parameters. All of it lives on the Services tab of the stand page.

This is also where the most frequent task in PDM is done — putting the version you need onto a stand.

Where values come from

Every setting has two “floors”.

• The default value is shared by all stands. It is set once for the platform as a whole and is changed only through a release.
• An override is the value for this particular stand. If it is set, it is the one that applies, and the shared value is ignored.

The rule is simple: if there is an override, it wins; if there is none, the default value applies.

This scheme exists so that no stand has to be described from scratch: almost everything comes from the shared settings, and only what really has to differ differs on a particular environment — for example, the version of the one application currently being tested.

How to tell where a value came from

Look at the colour of the badges, both in the application row (the Deployed version column) and next to the name of each parameter inside an expanded card.

Badge	Meaning
Blue	The default value, shared by all stands
Orange, tooltip “Overridden”	This stand's own value — this is what applies
Green, tooltip “Changed”	Your unsaved edit, not yet on the stand

If a parameter shows only a blue badge and an input field, there is no override and the stand runs on the shared value. Once an orange badge appears next to it, the stand is “detached” from the shared value for that parameter.

Next to the parameter name, in a small monospace font, its technical name is shown — the very name of the environment variable the setting reaches the application under. That is handy when you need to match a setting in PDM with what you see in the logs or in the application's documentation.

The Reset to base value action removes the override and returns the stand to the shared value; if the edit has not been saved yet, it simply discards it.

How to change a setting

An application's parameters live in its card on the Services tab, grouped by meaning; parameters with no group end up in the Other section. The editor depends on the parameter type: a yes/no toggle, a text field, an integer or floating point number, a version number split into segments, a dropdown list or an application action (see below).

Changes are not applied immediately — they accumulate as a draft.

The pending changes panel

All accumulated edits are collected in the “Pending changes: N” panel as “application — parameter: before → after”. You can revert a single edit or all of them at once (Discard all).

The Deploy changes button applies the edits — it is only visible if you are allowed to change this stand's configuration. Until you press it, nothing on the stand changes. Both buttons ask for confirmation first — Discard all changes? and Deploy changes?.

A version as the result of a build

A special kind of parameter is an application action. Instead of typing a version by hand, you can pick an action: build an image from a code branch or from a version number, for instance. The value of the parameter then becomes the result of the build — the tag of the image that was built.

The chosen action has fields of its own — a branch, a tag or a version number; the Additional information block shows reference values such as the current version.

In practice this means that “deploy a freshly built branch onto the stand” is a single action — the build and the version change happen within one operation, with no manual copying of the build number.

What happens after saving

Pressing Deploy changes starts a workspace — a long-running operation broken down into steps. It runs in the background and you can watch it.

Step by step, this is what happens:

1. Only the parameters that actually changed are picked up; untouched ones are left alone.
2. If a parameter's value is defined by an application action, the build runs first and its result becomes the parameter's value.
3. Once all values are ready, the final step writes them into the stand's configuration and applies them to the running environment.
4. After a successful apply, PDM updates the stored values on its side — you see them on the Services tab the next time you open it.

How long this takes

If you only changed ready values, applying them takes seconds. If a build is among the changes, the operation lasts as long as the build does — usually minutes, sometimes longer. The build step stays in the “running” state all that time, which is normal.

How to tell that it was applied

The progress of the operation is visible in the Workspaces section — look for a workspace named along the lines of “[stand name] Update config”. The details of each step contain its logs, and build steps have a direct link to the pipeline.

Signs that everything went through:

• the workspace status is Completed and every step is marked as done;
• on the stand's Services tab, after reopening it, the new values are shown as the ones in effect and the pending changes panel is empty.

If something went wrong, the workspace gets the Failed status, and the list of steps immediately shows where it stopped; the step details contain the error text.

Changes reach the real environment

Applying a configuration is not a “draft inside PDM”. The values are written into the stand's configuration and applied to the running environment: applications re-read their settings and may restart, and a version change means a different image is deployed. On a stand somebody is using right now, everyone will notice.

Before pressing Deploy changes:

• check that the right stand is open — stand names repeat across clusters, go by the cluster and the project label in the header;
• read the whole list of changes in the panel: everything you edited ends up there, including edits in other applications;
• make sure nobody else's work — testing or a demo — is going on at the stand right now.

An applied operation cannot be undone. The only way back to the previous state is another configuration change.

If something does not work

• The Deploy changes button is missing. You are not allowed to change this stand's configuration. The permission is granted on a specific scope — the button may well be there on a neighbouring stand but not here. See Permissions.
• The operation fails with an error about a GitLab token. Applying a configuration runs on your behalf, and that requires a personal GitLab token in your profile. Fill in the GitLab token field in your account settings and repeat the operation.
• The stand has never been synchronised. PDM has to know where to write this stand's configuration; that information appears during synchronisation with the infrastructure. If the stand has only just appeared, wait for the next synchronisation.

What's next

• Stand page — where the Services tab is and what its columns show.
• Releases — how to change a setting on many stands at once.
• Workspaces — how to read the steps of a long-running operation and its logs.