Bridging Infrastructure and Data#

Marco Martinez — Swisscom (Infrastructure Automation Architect)

• Why: An IPAM-relevant engineering talk: dynamic, SoT-driven resource allocation (e.g. "give me an unused IP") pushed directly into Terraform, solving the impedance mismatch between dynamic schemas and static provider definitions.
• What: A proof-of-concept custom Terraform provider for Infrahub, powered by GraphQL, that eliminates static .tfvars files and makes infrastructure data (unused IPs, standard vSwitch configs, cloud-provider IP reservations) directly available — read-only and read-write — inside IaC workflows, with an automated pipeline that builds and publishes the provider.
• How: The core problem is that Infrahub has a dynamic schema (no default schema; it changes per instance and branch) while Terraform providers expect static schemas in Go — and no Go SDK existed for Infrahub. The solution: a generator that takes your GraphQL queries, uses genqlient to produce a typed Go SDK, and templates a provider from them — schema baked in per version, published to a private registry, make all to build. Documented honestly: the design choices brought significant complexity, and self-built providers are not the norm.
• Where applicable: PoC-stage and Swisscom-context; the pattern (dynamically generating a provider from queries rather than hand-maintaining one) generalizes to any GraphQL-backed SoT/IPAM system (Infrahub, or similar). Directly relevant to anyone who wants IPAM allocation to happen inside Terraform plans instead of spreadsheets.