member badge
Andreas Grub
Introduce building_block_definition_version_spec resource in meshStack Terraform provider
Problem / Use Case
The current
meshstack_building_block_definition
Terraform resource bundles the Building Block Definition (BBD) entity — which holds the stable UUID and WIF subject — together with its version spec (inputs, implementation config, release state) in a single resource.
This creates an unresolvable circular dependency in a common Workload Identity Federation (WIF) setup:
  1. You create
    meshstack_building_block_definition
    to get the BBD UUID and its WIF subject claim.
  2. You configure your backplane (e.g., an AWS IAM role trust policy, a GCP WIF pool principal) to trust that WIF subject.
  3. The backplane outputs (e.g., the IAM role ARN or GCP pool ID) must then be passed back as
    static inputs
    to the BBD's version spec.
Because the BBD entity and its version spec are coupled in a single Terraform resource, Terraform cannot:
  • Create the BBD (to obtain the UUID/WIF subject),
  • Configure the backplane using that UUID,
  • Complete the BBD version spec with backplane outputs —
...all in a **single
terraform apply
**. The dependency graph becomes circular within a single resource boundary, forcing platform engineers to split the apply into multiple manual steps.
This affects any WIF-secured BBD where the backplane provides both the trust configuration
and
a static input to the same BBD version spec — a common pattern in real-world platform engineering setups.
Value / Impact
Introducing a separate
building_block_definition_version_spec
resource (decoupled from
meshstack_building_block_definition
) would allow Terraform to resolve the full dependency graph in one pass:
  • meshstack_building_block_definition
    creates the BBD and exposes its UUID and WIF subject as computed attributes.
  • Downstream backplane resources (IAM roles, WIF pool providers) consume the WIF subject.
  • meshstack_building_block_definition_version_spec
    consumes backplane outputs as static inputs — referencing the BBD created in the same configuration.
This unlocks:
  • **Single-pass
    terraform apply
    ** for the complete BBD + backplane setup, even when backplane config flows back as a static input to the BBD version spec.
  • Full GitOps automation
    — the entire BBD lifecycle (definition, version spec, backplane trust) is declared in one Terraform configuration, without manual sequencing.
  • Reduced operational risk
    — no more partially-applied states from multi-step apply workflows.
  • Natural alignment with the meshStack API
    , which already models
    meshBuildingBlockDefinition
    and
    meshBuildingBlockDefinitionVersion
    as separate objects.
This is especially impactful for platform teams managing many BBDs with WIF-secured backplanes, and for reusable Building Block Hub modules where full automation is a key requirement.
Context / Links
If you're hitting this issue, reach out to our customer success team or support@meshcloud.io — we'd love to understand your specific setup and help prioritize this.