Any way to read provider config in a diff suppress function?

[harryw]

Hi there. I’d like to ask for some advice on handling provider config in a custom provider.

I have a custom TF provider that works with some internal APIs. I’m trying to add provider config so that people who use this provider can control which API endpoints are used if they need to. I’ve done that so far by adding a config schema to the provider, and using a ConfigureFunc that reads that config data and returns it in a custom type so that it’s passed in as the ‘meta’ argument in resource CRUD functions, and in CustomDiff functions. However, I haven’t yet been able to figure out how to access that same data in a DiffSuppress function, which is a problem because for various (not-that-interesting) reasons I need to make an API call to check whether a proposed TF state change actually represents a change in resource state. So I need to get that API endpoint from the provider config during a diff suppress function. What’s the best way to do that?

If there’s no way to access the provider config directly from this function, then is it safe for me to copy this provider config to a global variable and then read it from there? I’m guessing that the provider is only instantiated once per process but I’d like to be sure.

Thanks in advance for any suggestions.

Harry

[paddy]

@harryw

However, I haven’t yet been able to figure out how to access that same data in a DiffSuppress function, which is a problem because for various (not-that-interesting) reasons I need to make an API call to check whether a proposed TF state change actually represents a change in resource state

There is, in fact, no current way to support this, unfortunately. DiffSuppressFuncs don’t get access to the provider configuration.

@harryw

If there’s no way to access the provider config directly from this function, then is it safe for me to copy this provider config to a global variable and then read it from there? I’m guessing that the provider is only instantiated once per process but I’d like to be sure.

It is when run in production, it is not when run in tests (in version 2 of the SDK, at the very least). I’d say this will probably work mostly fine, but it’s not really… recommended. Most people use CustomizeDiff for this functionality, though that’s a rather large hammer to wield.

We’re aware this is a shortcoming, and are working on potential mitigations of it, but have nothing to announce at this time.

[harryw]

OK, thanks for the response @paddy, it’s great just to have a confirmation that I haven’t missed anything.

I know nobody likes global variables, I’m certainly not enthusiastic about it myself but it sounds like it’ll be an acceptable compromise for now.

The advice is much appreciated, thanks.