Skip to content

Pinggy

Cloud provisioning

Creating monitoring nodes in OpenStack, how a new node is admitted, and when Pinggy may delete what it created.

What cloud provisioning is

An installation administrator can have Pinggy create monitoring nodes for a tenant in an OpenStack project, instead of enrolling a node by hand. The instance installs the same pinggy-monitor agent as any other node and enrolls with a one-time token. Tenant Owners keep every right they have over their nodes and never see cloud accounts, credentials or cloud identifiers.

Verification status. Cloud provisioning has been verified against a simulated cloud and the OpenStack project's published API samples only. It has not been verified against a live OpenStack deployment. Test it in a disposable project before relying on it.

A new node is held until it proves itself

A provisioned node is created disabled, as a member of its provisioning operation. While it is held it is never given monitors, cannot be enabled by anyone, and does not count toward quorum or health. It is admitted only when, within its validation deadline (30 minutes from the create call unless the administrator chooses 10 to 120 minutes), it:

  • enrolled with the token minted for it;
  • is live and has run for at least 120 seconds;
  • reports the agent version the operation expects;
  • passes the HTTP, TCP, TLS and DNS platform checks, and ICMP (or the administrator accepted an unknown ICMP result);
  • passes the egress check. A provisioned node cannot be excluded from it.

If any condition is not met by the deadline, or you revoke the node or cancel the operation, the node is revoked and the instance is handled as a failed attempt. A tenant sees the operation, who started it, each node's state and a short reason on /nodes/operations.

Publishing the egress address

When the installation publishes any monitoring source address, a provisioned node's own address must be published before it can be admitted. A node without a floating IP leaves through the cloud's shared outbound address, so the administrator must publish that address within the validation deadline, or the node fails validation.

Deleting what Pinggy created

Terminating an instance is destructive and happens in someone else's infrastructure, so it is off by default. Pinggy deletes an instance only when all of these hold, checked again immediately before each delete:

  • the deployment's configuration enables it;
  • an installation administrator has activated cloud deletion;
  • the deployment still matches what was attested, and has not gone silent;
  • the instance's recorded identity, tags and metadata match what Pinggy created;
  • the cloud project carries this deployment's ownership marker;
  • the node was retired or never activated.

If any of these cannot be established, nothing is deleted. The instance stays running and is listed for an administrator. Pinggy never deletes an instance by name, never touches networks, routers, ports or security groups it did not create, and never deletes its own ownership marker, a security group the administrator removes by hand when finished with the project.

Restores and clones

Pinggy cannot tell a byte-identical clone of an installation from the original. A restore or copy started with the same database and configuration keeps its permission to delete. The required procedure is to start every restored or cloned deployment with cloud deletion disabled in its configuration, then re-attest, and only then enable it. Pinggy detects a restore into a new database or a new cluster and a clone whose nodes go silent, but these are backstops. The procedure is the control.

The repository documents the details for administrators: cloud accounts and the least-privilege credential, the provisioning workflow, the deletion gate, reconciliation, the provisioning token threat model and the restore procedure.

This article is part of this repository and is served by the same binary, so what you read here is the documentation for the version you are running.