Access provider configuration within a validateFunc

The CRUD functions within a resource CreateFunc, ReadFunc etc have access ConfigureFunc which in my case is an API client, is it possible to expose/pass this to a validateFunc at all?

Not at this time. The alternatives are to validate using CustomizeDiff (any error returned will return as a plan-time error) or to validate in the CRUD method itself and error at apply-time.

Hi @paddy,

Thanks for the CustomizeDiff idea, i’ll give that a go - as i was hoping to get plan-time validation.

Thanks!

Hi,

I tried the CustomizeDiff idea, worked really nicely - I have just been testing the new v2.0.0-rc.1 and started looking at the diag.Diagnostics to help aggregate feedback better but the CustomizeDiffFunc doesn’t support it yet, is this something that would be considered?

Happy to raise a feature request if it is!

Thanks!

Please feel free to open an issue if one doesn’t exist.

I think we would probably rather have an “online validation” hook though than pushing people to repurpose CustomizeDiff just for the plan time hook. This issue may already be kind of what you are looking for: https://github.com/hashicorp/terraform-plugin-sdk/issues/101

I recently found an limitation with the CustomizeDiff approach in that if i Get a field which is interpolated its empty, if you look at the simplistic example:

resource "foo" "bar" {
  configuration = <<EOF
  {
     "a": "foo",
     "b": "bar
  }
  EOF
}
resource "bar" "foo" {
  configuration = <<EOF
  {
     "a": "foo",
     "b": "${foo.bar.id}"
  }
  EOF
}

Resource foo.bar can be validated, bar.foo cannot. I can’t see any methods on *schema.ResourceDiff which could get me the un-interpolated values (i’m only doing key presence validation). Is it possible to handle this sort of use case?

At this time, no.

I’m also not sure how this would work. Think about the order of events:

You want the validation to happen before apply time, which means the value must be known before apply time. But the ID of foo.bar is inherently an unknown value until after foo.bar has finished applying, because it’s not in the config. After the first apply, it should be in the state, which means its value should get provided to CustomizeDiff, but again, that’s only when a value already exists in state, which won’t be the case on the first apply.

If you were to reference foo.bar.configuration, I believe that should show up in CustomizeDiff, as it is a known value when CustomizeDiff runs.

We’re hoping in future versions of the SDK to make this problem clearer by surfacing that a value is unknown, instead of just using the empty value to indicate that.

Yeah my tests work for foo.bar.configuration I wasnt sure if it was possible to get the original raw unknown value:

{
  "a": "foo",
  "b": "${foo.bar.id}"
}

But I’m thinking about this it might be problematic anyways as i’d probably never be able to handle situations like this well:

{
  "a": "foo",
  "${foo.bar.id}": "bar"
}

I’ll just handle the case for if the value is unknown silently ignore it and only validate examples with known state.

Thanks @paddy