Servers and plans

A plan is a saved order. It exists so that the thing you sell twenty times is described once, and so that a colleague ordering it cannot get the details subtly wrong.

VPS plan

Cores, memory and disk, plus the address pool to draw from and optionally a bridge. It is not tied to an integration, so the same plan works on every hypervisor you connected.

Web plan

One hosting package on one control panel, under a name of your own. The package name is stored as it was at the time. It is a reference to something on your server, not a copy of its contents.

Game plan

The whole container on one game panel: the egg, optionally an image and a startup command, the variable values, the limits and the feature limits. Ordering a game server without a plan is not possible.

The order form has two steps. The first is what you are ordering; the second is the detail. An integration that is not ready to be ordered from is listed with the reason and a link to the tab that fixes it.

• For a hypervisor you pick the integration, optionally a plan, and the operating system. Without a plan you fill in the specification yourself, bounded by what the node can actually offer where the agent has measured it.
• For a control panel you pick a web plan or a loose package, then the username, the domain, the email address and the password.
• For a game panel you pick a game plan and a name. Those are the only two fields.

If the plan carries an address pool, the address comes from there and the manual picker disappears. Without a plan you can take the next free address from a pool, pin a specific one, or take none at all.

The buttons follow the provider. A hosting account has no start button because there is nothing to start; a game server has a kill button because containers sometimes need one.

• Virtual machines: start, stop, shut down, pause, resume, refresh, reinstall, resize and add disks, add and remove network cards, edit firewall rules, and delete.
• Hosting accounts: suspend, resume, change package, refresh and delete.
• Game servers: start, stop, restart, kill, suspend, resume, refresh, reinstall and delete.

• Overview: status, specification, addresses, the integration and agent it belongs to, recent usage, and the buttons.
• Statistics: the graphs, over an hour, six hours, a day or a week.
• Network: the addresses Provibr assigned next to the addresses the agent observed, the firewall rules and log, and the hardware addresses used for network installation.
• Hardware: disks and network cards, read from the machine itself.
• Console: a live screen or terminal, where the provider has one.
• Activity: every command and every event for this server, with the reason the agent gave.
• Settings: where it came from, reinstalling, network installation, changing package, and deleting.

Two of them are easy to confuse, and the difference matters for your bill.

• Provisioning: Provibr is creating it. The clone or the create call is still running.
• Installing: the machine is configuring itself, through cloud-init or through a network installation. It counts as running.
• Running, stopped, error, unknown: what the system reports back.
• Suspended: switched off and locked. Either you did it, an administrator did, or the platform did because you went over your licence limit.

The agent polls every twenty seconds and does a full comparison every few minutes, so a machine someone stopped by hand shows up as stopped within about that time. A few observations are deliberately ignored: a machine cannot report itself as running while it is still installing, and no observation from your infrastructure can lift a suspension the platform imposed for going over your limit.

A resource that exists on your system but has no record in Provibr is ignored on every poll, counted, and logged once. That is why your own production machines never appear in the panel by themselves.

Where a provider can list what it runs, its integration has an import tab. You get the list, tick what you want and it becomes a server in Provibr with its real identifier. No placeholder, no second record.

This works wherever an integration can list what already runs on it, whether virtual machines, hosting accounts or game servers, so nothing on a connected system has to be recreated by hand.