Fdb.Provisioning

Namespace: FoundationDB.Client · class

Helper class for provisioning a database on a freshly created cluster

Remarks

A FoundationDB cluster on a brand-new storage volume has no database until configure new runs once. Until then every transaction hangs and status reports the database as unavailable.

The client API cannot write the database configuration, so the work goes through the fdbcli tool that ships inside the server's docker image; callers supply the way to run it (docker exec, Testcontainers exec, ...).

Methods

EnsureDatabaseConfiguredAsync

static Task EnsureDatabaseConfiguredAsync(FdbCliRunner runFdbCli, TimeSpan timeout, string configuration = "single ssd", TimeSpan? probeInterval = null, Action<string> log = null, TimeProvider time = null, CancellationToken ct = null)

Ensures that the cluster reachable by runFdbCli has a configured, available database, creating it if the volume is fresh

• runFdbCli — Runs fdbcli against the cluster (for a docker container: docker exec <container> fdbcli <arguments>)
• timeout — Maximum total time to wait for the database to become available
• configuration — Configuration given to configure new (defaults to "single ssd", the single-node local dev shape)
• probeInterval — Delay between two availability probes (defaults to 500 ms)
• log — Receives one line per outcome, so that a first run is never silent
• time — Time source for the availability wait (the deadline and the poll delay); defaults to the system clock. A test can pass a fake provider to drive the timeout with virtual time.
• ct — Token used to abort the wait

Idempotent and safe against concurrent starters: configure new refuses to touch an existing configuration, and that refusal counts as success.

Every fdbcli invocation passes --no-status: the initial status check would itself wait 30 to 60 seconds on the unconfigured database this method exists to fix.