M
Mark Tarry
The current Terraform provider (v2.13.4 at the time of raising this) has distinct resources for
port_blueprint
and
port_aggregation_properties
. This enables developers to avoid circular dependencies between blueprints and aggregate properties in various scenarios.
thumbs up
However, the same circular dependency problems can arise with calculation properties. Take the following example of calculating the DORA "Change Fail Rate" metric:
Blueprints:
service
,
incident
and
deployment
(both
incident
and
deployment
have a relationship back to
service
)
The
service
blueprint includes aggregate properties;
count_incidents_in_last_week
and
count_deployments_in_last_week
(both counting entities, with a filter on a date property in the respective blueprints)
The
service
blueprint then also includes a calculation property for the DORA metric:
(.properties.count_incidents_in_last_week / .properties.count_deployments_in_last_week) * 100
Port lets you set this up via the web app. But when deploying via Terraform we create circular dependencies:
resource "port_blueprint" "service" {
calculation_properties = {
dora_change_fail_rate = {
# Depends on port_aggregation_properties.service_aggr else we cannot add property
calculation = "(.properties.count_incidents_in_last_week / .properties.count_deployments_in_last_week) * 100"
}
}
}
resource "port_aggregation_properties" "service_aggr" {
# Depends on port_blueprint.service, else the aggregates cannot be added
blueprint_identifier = port_blueprint.service.identifier
properties = {
count_incidents_in_last_week = {...}
count_deployments_in_last_week= {...}
}
}
If calculation properties were a distinct resource type, rather than embedded in the
port_blueprint
resource, then we could avoid such circular references.