Don't block terraform on provider initialization

[mandrav]

I 'm using this provider in a project which, using terraform workspaces, deploys the same set of resources in different environments. In one of these environments (the dev one), pihole is used through this provider.

The problem is that when I run terraform commands in workspaces where pihole is not available, this provider still expects valid url and api_token values. Sample of output:

Error: client validation failed: Pi-hole URL is not set
│
│   with provider["registry.terraform.io/ryanwholey/pihole"],
│   on provider.tf line 36, in provider "pihole":
│   36: provider "pihole" {

I even tried setting the url to something (e.g. http://localhost), just as a workaround, but the same error occurs (possibly trying to contact a valid pihole installation). I was wrong, it just checks for string emptiness (sorry, had forgotten to re-source my vars file)

Considering terraform does not support conditional providers (which I 'd prefer and also would have solved my problem), this is a showstopper for us.

Is it possible to disable any url (and other variables) validation until they 're actually used?

[ryanwholey]

Hi thanks for submitting! Yes I think this would be a nice feature to have. I should have some time coming up over the next few months to look at maintenance/features for this provider, but PRs are always welcome 🙏

[maddiecs84]

I've hit this problem as well. In my case I am using terraform to deploy the pihole instances and then wish to configure them.

I have the following that fails with the same error due to the url and password not being available at the time the provider is defined.

provider "pihole" {
  url      = "http://${local.primary_ip}"
  password = "${local.admin_password}"
}

[ryanwholey]

@maddiecs84 yep makes sense. I took a look at the implementation this evening and it should be relatively straight forward. I'm optimistically looking to add this in the next couple weeks 🙏

[ryanwholey]

@mandrav thank you again for submitting this issue. I've released version 0.2.0 which I believe should resolve this issue.

In a workspace that defines the provider but has no available pi-hole server (and doesn't intend to manage resources of course) the following config no longer errors.

provider "pihole" {
  url       = "stub"
  api_token = "stub"
}

resource "pihole_cname_record" "record" {
  count = 0

  domain = "foo.com"
  target = "bar.com"
}

@maddiecs84 your dynamic provider scenario should now also be possible and I've added docs describing a potential configuration. Perhaps longer term we can add some timeout and retry cadence logic to the client to avoid using a null_resource while pi-hole comes up.