CoreCP

Assigning servers to rollout waves

A new version never reaches every server at once. It walks in waves: a canary first, then wave 1, then the rest, with a wait and a health check between each pair. Which server is in which wave is your decision.

Written for: Administrator

A new version never reaches every server at once. It walks in waves: a canary first, then wave 1, then the rest, with a wait and a health check between each pair. Which server is in which wave is your decision.

At four servers you make that decision by dragging cards. At two hundred you do not. This page is about the way that scales: you describe your fleet with rules, and the panel derives the assignment from them — including for the servers you add next month.

Administrators only. Resellers and end customers never see this screen.

Open Fleet → Releases. At the bottom are three things, in the order you use them: the rules, the board with the waves, and the exception.

In short

What you wantHow
A whole group of servers in one waveWrite a rule: "tag = nl → wave 2"
A handful movedTick them and choose Move selection to
One server somewhere elseDrag it, or open it and pick a wave
To know why a server is where it isLook at the badge after its name
To see what a rule will do before saving itClick Test

1. Give your servers labels

A rule selects on four things: node group, region, role and tag. The panel already knows the first two (the group the server is in, and the roles it runs); region and tags are yours to set.

  1. Click a server on the board. A panel slides open.
  2. Under Labels, pick a key (region or tag), type a value and click Add label.

region always holds one value — a server in two regions would make every region rule ambiguous. tag may hold as many as you like.

The terminal does the same, which is easier for a whole batch:

# root@panel1
$ corecp-panel waves label stck1.corecp.dev region=nl tag=ssd
NODE              KEY     VALUE
stck1.corecp.dev  region  nl
stck1.corecp.dev  tag     ssd

2. Write a rule — and test it first

  1. Click Add rule under Assignment rules.
  2. Give it a short name (nl-to-wave-2), pick When (say tag), type the value and pick the wave.
  3. Click Test.

Testing writes nothing. It shows you, per server, what would really happen — which is not the same thing as "which servers match":

  • move to wave X — these will actually move;
  • stay (already there) — these are in that wave already;
  • stay — placed by hand — somebody put this server here, and that outranks every rule;
  • stay — rule Y takes it first — a rule higher in the list claims it before this one gets to it.

Under the list is the arithmetic, and the sentence "Nothing has been saved yet." Does it look right? Click Save. The panel applies the rule at once and says how many servers moved.

3. The order is the policy

Rules are read top to bottom and the first one that matches wins. The ↑ and ↓ arrows move a rule earlier or later. Every change recomputes the fleet immediately.

A common example:

1  dns-to-wave-1     role = dns    → wave 1
2  nl-to-wave-2      region = nl   → wave 2
3  rest-to-wave-3    role = web    → wave 3

A Dutch DNS server ends up in wave 1, not wave 2 — because rule 1 comes first. If you want it the other way round, move rule 2 to the top.

4. Not yet assigned

A new server does not land in a wave by itself. It arrives in the Not yet assigned group and stays there until a rule takes it or you assign it.

That is deliberate: a machine whose blast radius nobody has judged should not end up in the first, riskiest wave by accident. But it is not a resting place either — a server in that group receives no rollout at all. The board says so, and a rollout plan names the machines it is therefore skipping.

The quickest fix is usually to give the server the label you already use; an existing rule picks it up the next time the board is opened.

5. In bulk: several servers at once

  1. Type in the search box what you want to filter on — a name, a region, a role, a tag. The board narrows with you.
  2. Tick the servers you want to move.
  3. Pick a wave at the top right and click Move selection to.

That is one action, one audit row, and every selected server is afterwards marked manual — so no rule will move them back later.

6. Why is this server here?

Every server name carries a badge:

BadgeMeaning
manualSomebody put it here. The tooltip names them. No rule will move it again.
rule <name>This rule placed it. Change the rule and its wave changes with it.
automaticIt was placed before the rules existed. A rule may take it over.
no ruleIt is in Not yet assigned.

7. An exception stays an exception

Dragging still works. Pick a server up and drop it on another wave card — for that one machine that belongs somewhere else for a reason of its own. Such a move is manual and survives every later recomputation of the rules.

Does the panel ask for a confirmation?

Not for assigning. Putting a server in a wave installs nothing, reaches no machine and is undone by dragging it back. That does not deserve a password prompt.

Yes for rolling out. Promoting a release or starting a rollout touches the whole fleet. There the panel asks for your second factor again, in a proper dialog — you type your code, click Confirm, and the action you wanted carries on. Nothing is lost.

Everything from the terminal, too

# root@panel1
$ corecp-panel waves board            # the whole board, with the reason per server
$ corecp-panel waves rules            # the rules, in evaluation order
$ corecp-panel waves rule test nl-to-wave-2 --on region --is nl --to wave-2
$ corecp-panel waves rule add  nl-to-wave-2 --on region --is nl --to wave-2
$ corecp-panel waves move stck1.corecp.dev wave-1 --busy
$ corecp-panel waves apply --dry-run  # what a recomputation would change

See also