[FEATURE] Support for hashicorp/random

[BernieWhite]

Your suggestion

Investigate emulating common hashicorp terraform providers functions like random_string from hashicorp/random that are likely to be encountered by customers.

For example, the following code would not work currently if var.container_registry_name is not set because random_string.acr_name.result is calculated at apply time so the result is an empty name field. The current implementation will skip a resource if the name is set to an empty string.

resource "random_string" "acr_name" {
  length  = 10
  special = false
  upper   = false
  numeric = false
}

# Manage a container registry resource.
resource "azapi_resource" "example" {
  type      = "Microsoft.ContainerRegistry/registries@2020-11-01-preview"
  name      = coalesce(var.container_registry_name, random_string.acr_name.result)
  parent_id = azurerm_resource_group.rg.id

  location = azurerm_resource_group.rg.location
  identity {
    type         = "SystemAssigned, UserAssigned"
    identity_ids = [azurerm_user_assigned_identity.example.id]
  }

  body = {
    sku = {
      name = "Standard"
    }
    properties = {
      adminUserEnabled = true
    }
  }
}

While the intent is that the name is random (the first apply), for testing with PSRule it may make sense to make this appear random but deterministic taking parameters from the resource definition name to seed then getting the N'th variation based on how many times it's called. Otherwise subsequent runs would report a different name.

Alternatives

n/a

Additional context

• https://learn.microsoft.com/en-us/azure/developer/terraform/get-started-azapi-resource?tabs=azure-cli

[BernieWhite]

@jaredfholgate thoughts on a prioritized first list that are going to be a problem for AVM customers?

[jaredfholgate]

@jaredfholgate thoughts on a prioritized first list that are going to be a problem for AVM customers?

@BernieWhite I think I may be missing some context here? I thought the idea was to run a Terraform plan and run any tests against the plan output?

Are we saying that test assertions may fail if the plan changes? Apologies if I am missing something obvious here.

[BernieWhite]

@jaredfholgate random_string is calculated at apply time, so the plan does not have a resolved value for a new resource until that's calculated. Does that make sense?

[jaredfholgate]

@jaredfholgate random_string is calculated at apply time, so the plan does not have a resolved value for a new resource until that's calculated. Does that make sense?

It does, but I'm unsure how that may impact the test assertions? If we are looking for things like Well Architected Framework compliance, then we only need the resource type and settings like zones, etc. Perhaps we don't need this extra functionality for iteration 1?