Add field(s) allowing to read provider configuration from Secret/ConfigMap

[sbx0r]

Hi! We are using azurerm provider which requires defining additional features {} field within the provider's block. Due to that. we have to define provider blocks within the modules because setting features {} block via environment variable makes it unreadable, especially when you need to configure it. I'm wondering if could we extend Terraform CRD by new fields providerConfig and providerConfigsFrom which will act like backendConfig and backendConfigsFrom?

What do you think about it?

[chanwit]

Hi @SebastianBakala-TomTom Thank you for bringing this up. It's an interesting approach.

Would you elaborate more about this. Maybe some examples of the spec.providerConfig that you're looking for. I also had an idea around type-safe structures for backends. Maybe we would consolidate these concepts together.

[sbx0r]

Hi @chanwit Sorry for late response. I was really busy.

I'm not an expert in Go so the idea can be wrong 🙂. Please correct me if so.

This is what comes to my mind:

schema:

spec:
  providerConfig:
    - name: azurerm
      source: hashicorp/azurerm  # OPTIONAL: If you want to download eg. partner's provider like databricks  (databricks/databricks). Otherwise, default terraform's behavior
      version: '~> 3.0'  # OPTIONAL: if not set: default terraform's behavior
      meta-arguments:
        features:
          some: fields
          #...
        subscription_id: <sid>
      #...

this could be parsed by tf-controller and pushed to tf-runner for example. Resulting provider-{spec.providerConfig[n].name}.json:

{
  "provider": {
    "{spec.providerConfig[n].name}":
      [
        "tip": "Due to possibility to use different aliases for the same provider",
        "tip": "spec.providerConfig have to be parsed properly"
        {
          "# parsed meta-arguments"
        }
      ]
  }
}

pseudo algorigthm for parsing:

1. get list of provider configs
2. group providers with the same names
3. parse meta-arguments for each provider
4. build a json file(s) with provider configurations

[sbx0r]

Hmmm. Or maybe different crd for terraform providers?

[sbx0r]

@chanwit Could you elaborate so we can confront our thoughts? I'd like to start implementing it

[squaremo]

Sorry for letting this fall through the cracks for a while, @SebastianBakala-TomTom. @chanwit The suggestion seems eminently sensible to me. Could we proceed on the basis that it follows the precedent set for backend config?

@SebastianBakala-TomTom If you're still interested in contributing (yay!) -- what support from us do you think you would need? Thanks for your interest in any case :-)