PDM

Core concepts ​

The PDM interface is built around a dozen concepts. They are covered below in order — from the largest to the smallest.

How it all fits together ​

The entities nest inside one another:

  • a cluster contains projects;
  • a project contains stands;
  • platform applications run on a stand;
  • every application on a stand has its own settings and its own version.

That is why the same stand is always identified by a pair — cluster plus name: stand names repeat across clusters, and a test one is easy to mistake for a production one.

Cluster ​

A cluster is a separate Kubernetes site that environments are deployed on. It is the top level of the hierarchy. There are usually several clusters, and they differ in purpose — for testing and for production work, for example.

PDM does not maintain the list of clusters by hand; it receives it from the infrastructure. Connecting clusters is an administrator's job.

Project ​

A project groups stands inside a cluster. It has no page of its own: it is shown as a label next to the stand name and helps you tell which team or area the stand belongs to.

Stand (namespace) ​

A stand is a specific environment: one deployed copy of the platform with its own set of applications, its own settings and its own address. It is the main object of the system, and almost all work in PDM revolves around it.

Technically a stand is a namespace in a Kubernetes cluster — an isolated slice of the cluster with its own set of running applications. The word "namespace" shows up in page URLs, but the interface and this documentation use the more familiar "stand".

Example: the prj-demo stand in the testing cluster is a separate copy of the platform where you can check changes without disturbing anyone else.

Platform application ​

A platform application (in the interface — “Service”, “Component”) is one of the parts the platform is made of: the user interface, a backend service, a utility component. The platform is assembled from several such applications, and on every stand they all run together.

An application has a name, a set of configurable parameters and a version deployed on a particular stand. The application catalogue is maintained by an administrator — the applications are the same for every stand, only their versions and settings differ.

Stand configuration ​

The stand configuration is all the settings of the applications on that stand. Each setting is a separate parameter: a checkbox, a string, a number, a version number or a choice from a list.

A parameter has two levels:

  • the default value — shared by the whole platform, the same for every stand;
  • the override — a value set for this particular stand.

The rule is simple: if the stand has an override, the override wins; if it does not, the default value applies.

Application version ​

The application version is the image tag deployed on a stand. Formally the version is a configuration parameter like any other, just pulled out of the general settings list.

Application action ​

An application action is an operation you can trigger for a particular application: build an image from a branch, build a new version or simply point at a ready tag. Every action ends up producing an image tag — and that tag becomes the application's version on the stand.

Hence the most common way of working: instead of typing a version by hand, you pick the build-from-a-branch action and PDM fills the tag of the built image into the stand's settings for you.

Build and pipeline ​

A build is a run that prepares an application image. PDM builds nothing itself: it triggers a pipeline in GitLab — a preconfigured sequence of steps that compiles the code and publishes the image.

While the pipeline runs, PDM polls its state periodically, so a build step can stay “Running” for a long time — that is normal. In the interface a build carries a link to its pipeline and its log.

Release ​

A release is a single agreed configuration change rolled out to many stands at once. Unlike an edit of one stand, a release updates the default values (so it affects everyone), decides separately what to do with stands that have their own overrides, and finishes with a mass application of the changes.

Releases are numbered and stay in the history: you can see who created one and when, what changed and how it ended.

Workspace ​

A workspace is one long-running operation broken into steps. Deploying stand settings, building and releasing all run this way. Each step has its own status, data and log, and the steps themselves are wired into a graph: some run in parallel, and the final step waits for all the others to finish.

Thanks to this, a button in the interface reacts instantly while you watch the actual work separately — and what you see is not "running or not running" but the specific step the operation is on.

In short ​

TermWhat it is in one line
Clustera Kubernetes site that projects and stands live in
Projecta grouping of stands inside a cluster, a label next to the stand name
Stand (namespace)a separate environment — one deployed copy of the platform
Platform applicationa part of the platform running on a stand
Configuration parameterone setting of an application on a stand
Default valuethe parameter's shared value for every stand
Overridethe parameter's own value on a particular stand
Application versionthe image tag deployed on a stand
Application actionbuilding a branch, building a version or setting a ready tag
Build (pipeline)preparing an application image in GitLab
Releasean agreed configuration change across many stands at once
Workspacea long-running operation broken into steps

One concept, several captions

The same concept is captioned differently in different places: a platform application appears both as “Service” (the “Services” tab) and as “Component” (the column in the configuration table), and a stand is still a namespace in page URLs. They are the same concepts.

What's next ​