Ilija Matoski

    ← Articles

    Typed resources for every AWX credential type

    A generic credential resource works, and it puts the whole burden of knowing what goes inside on whoever writes the terraform.

    For a long time the provider had a single credential resource, and you passed whatever the credential needed as a blob of JSON.

    resource "awx_credential" "aws" {
    name = "aws-prod"
    credential_type = 5
    inputs = jsonencode({ username = "AKIA...", password = "..." })
    }

    That works.

    It also means terraform has no idea whether username is a field this credential type has, so a typo is something you find out about from AWX at apply time, or later, when a job fails for a reason that has nothing to do with the job.

    The credential type already describes its own inputs, and AWX ships thirty of them, each with its own fields, so that’s thirty schemas we were throwing away.

    So the generator emits a resource per credential type now, thirty of them, built from the same description AWX hands out if you ask it.

    resource "awx_credential_type_amazon_web_services" "prod" {
    name = "aws-prod"
    organization = awx_organization.platform.id
    access_key = var.aws_access_key
    secret_key = var.aws_secret_key
    }

    Now a typo is a plan time error instead of an apply time one, the fields are in the documentation, and anything secret is marked sensitive so it doesn’t end up in the output.

    The notification templates got the same treatment, ten types, each with its own shape, and each of them previously a blob.

    The thing I’m least pleased about finding this year is that the provider had been generated from an incomplete description for years, because an empty AWX instance describes less of its API than it has.

    I wrote that up separately, it isn’t really a provider problem.

    The other thing that changed this year is the generator itself, which was part Node and part Go for historical reasons that were never good.

    The config merge is Go now, so the whole pipeline is one language.

    It also warns about overrides that do nothing, which sounds like a small thing, and it isn’t.

    An override in the config exists to correct something the API description gets wrong, and when AWX later fixes it upstream the override becomes a lie that nobody notices for two years.

    OpenTofu works too, which mostly meant not assuming the registry, and it turned out to be less work than I’d expected.

    All of it comes out of the same description AWX already publishes, including the documentation, which is the part I’d have got bored of writing long before it was finished.