Context around the log entry "...tolerating it because it is using the legacy plugin SDK."

[trentrosenbaum]

Hi there,

I am working over the fastly provider and testing it using the 0.12.1 SDK. After applying a plan I noticed the following lines in my local log file and I was wondering if anyone might be able to provide some context behind the entry.

2019/06/12 15:48:58 [WARN] Provider "fastly" produced an invalid plan for fastly_service_v1.foo, but we are tolerating it because it is using the legacy plugin SDK.
The following problems may be the cause of any confusing errors from downstream operations:
  - .activate: planned value cty.True does not match config value cty.NullVal(cty.Bool)
  - .default_ttl: planned value cty.NumberIntVal(3600) does not match config value cty.NullVal(cty.Number)

From what I understand during an SDK update I did not need to alter the schema definition, but I am concerned that I might have missed something. While it is marked as a warning now I want to be ahead of changes in the near future.

[apparentlymart]

Hi @trentrosenbaum,

This message is about the SDK rather than the provider. This is a quirk of the compatibility bridge that allows the existing (0.11-oriented) SDK to be compatible with Terraform 0.12 until a 0.12-native SDK is available.

There is nothing you can or need to do about these warnings: they are result of the fact that Terraform 0.11 (and thus its SDK) don’t have a concept of null and so the SDK compatibility bridge causes the planned value to disagree with the configuration by providing non-null placeholder values. These problems would normally be flagged by Terraform Core as an error, but there’s a special exemption for the old SDK to render them as errors instead so that releasing Terraform 0.12 would not block on completing the full SDK updates.

Sometimes this set of warnings does include useful details that help with diagnosing strange issues that result from quirks in the old SDK, and so that’s why we include the warnings here. The Terraform Core team uses variants of these warnings when we receive a report of a strange error that is caused by a provider or SDK bug that isn’t being caught because of this legacy SDK exemption.

If there aren’t any “confusing errors from downstream operations” (as the log message says) then there’s no need to worry about these warnings.

[trentrosenbaum]

Hi Martin,

Thanks for the feedback on this question. It was really appreciated.