Use the CMDB Pigsty Already Has

Ruohang FengAuthor of pig and founder of Pigsty.

Decision date: 2026-07-18
Status: The greenfield revision store is superseded; the thin existing-CMDB adapter is implemented and remains experimental.
Current reference: pig inventory cmdb
Scope: Exchanging declarations with Pigsty’s existing CMDB, not designing another configuration database.

Decision

PIG must reuse the CMDB already provided by Pigsty. Its responsibility is a bounded adapter: validate a static Inventory, load declarations into the existing tables, dump the existing projection, check consistency, and switch Ansible between the static and dynamic sources safely.

PIG does not own a second schema, migration history, snapshot ledger, compare-and-swap revision store, three-way merge engine, or rollback database.

Context

An early design treated CMDB support as a greenfield backend. It proposed a separate schema, immutable snapshots, revision tokens, merge and rollback operations, backup bundles, and source switch records. The design was internally coherent but started from the wrong premise: Pigsty already had the pigsty and pglog schemas, load scripts, dynamic Inventory projection, and source switching behavior.

Building a parallel control plane would duplicate facts, create synchronization problems, and make PIG responsible for a data model owned by another project.

Alternatives considered

• Keep the new revision store as an advanced mode. Rejected because two authorities are still two authorities, even if one is optional.
• Mirror between the new and existing schemas. Rejected because conflict resolution and migration would become permanent product responsibilities.
• Hide the existing scripts behind a shell wrapper. Rejected because PIG needs bounded timeouts, safe connection handling, structured plans, and atomic source switching.
• Remove CMDB support entirely. Rejected because a small native adapter adds useful validation and automation without redefining the schema.

Contract

• Pigsty’s existing schema and projections are the data-model authority;
• PIG connects through an explicit database target, environment configuration, or service=meta;
• credentials, DSNs, SQL bodies, and declaration values never enter plans or diagnostics;
• check is read-only;
• init applies the existing baseline and does not claim to back up an existing database;
• load replaces declaration rows transactionally and requires explicit confirmation;
• dump refuses an unexpected overwrite unless forced;
• enable and disable edit only recognized Ansible Inventory source forms and write atomically;
• unfamiliar executable Inventory sources are refused rather than rewritten;
• the entire command family remains labeled experimental.

Consequences

The correction deleted a large amount of already implemented revision-store code. That deletion was intentional scope recovery, not lost functionality: the removed features described a product PIG should not own.

The remaining adapter is smaller, easier to audit, and compatible with existing Pigsty operations. It also inherits the limits of that system: init needs an operator-managed backup, and loading a declaration set is a replacement operation rather than collaborative version control.

Verification and evolution

The corrected boundary was recorded in ba6e678. The abandoned implementation was removed in e0f73ed, deleting the parallel schema, snapshot, merge, revision, and rollback machinery. Tests for the retained path cover PostgreSQL compatibility, connection redaction, transaction failures, digest-pinned confirmation, dump safety, and atomic source switching.

Current status

The existing-CMDB adapter shipped in v1.6.0 but remains experimental. Operators should back up real CMDB state before initialization or replacement and use the current pig inventory documentation rather than the historical abandoned design.