8 Commits (7e767490c87bae2fa2b60da33ecefa1b7a220afa)

Author	SHA1	Message	Date
Martin Atkins	660ff86c4c	backendbase: Preserve unset arguments as null when not set by env ... Previously we tried a simplification where any attribute with an "SDK-like default" was guaranteed to never be null, because that seemed like a plausible mimic of the legacy SDK's general aversion to nulls. However, the SDK does still respect the absense of an argument as different to its zero value in one narrow case: when the argument isn't set in the configuration, also isn't set by any environment variables, and has no static fallback default. In that case, the SDK's built-in validation rules such as "ConflictsWith" _do_ treat absent as different from zero-value. To allow backends to continue making such distinctions themselves where that's useful, SDKLikeDefaults now leaves an attribute set to null if it wasn't present in the configuration and none of the environment variables or fallback value cause it to end up being a non-empty string. The backend can then choose to bypass the SDKLikeData API and check the cty.Value directly if it wants to distinguish set from zero even though SDKLikeData is designed to avoid the need to do that. This also updates the gcs backend to make use of the new facility, since it wants to raise an error if two arguments are both set even if they are both set to the empty string. Restoring that original error case is the main motivation for this change.	2 years ago
Martin Atkins	6bd1c66cbc	backendbase: Basic support for default values ... Some existing backends make very heavy use of environment variable-based default values and fallback values, which are available in the legacy SDK but not in Terraform's own schema model. To ease the migration away from the legacy SDK for those backends, backendbase.Base now supports a lightweight mechanism for declaring such defaults, and applies them automatically as part of PrepareConfig. This gets us pretty close to the assumptions that the SDK allowed callers to make, but with considerably less code. It's intentionally considerably less flexible than the legacy SDK was, because in practice most backends use only a tiny subset of the SDK functionality anyway.	2 years ago
Martin Atkins	b16cb49fb6	backendbase: "SDK-like" helpers ... A lot of the remote state backends' current Configure functions unfortunately rely quite heavily on the "do the best you can" API of the legacy SDK, which makes questionable shortcuts like treating null as equivalent to the Go zero value of a type, but in return makes it convenient to assign into other data structures that happen to make similar assumptions. And of course that means that the backends' other data structures were built to make those similar assumptions! This new set of utilities therefore aims to provide a bare-minimum subset of "SDK-like" functionality to ease the initial migration away from the legacy SDK. It isn't exactly equivalent an in particular focuses only on the small subset of legacy SDK functionality that most existing backends rely on, but this should at least make the initial adaptations a little more mechanical so that we can continue to defer the full modernization of these backends for some undetermined future time without having to continue retaining the huge legacy SDK snapshot in this codebase.	2 years ago
Martin Atkins	2222c23d4b	backendbase: BoolValue and MustBoolValue ... With legacy helper/schema it's common to just type-assert whatever ResourceData.Get returns and trust that it'll always be valid. We can't achieve something quite that lazy with cty, but we can at least factor out the work of turning a value we already know is a bool into a bool value. We also have a "must" variant for this one, because it's relatively easy for a caller to ensure that it controls all of the inputs enough to ensure that it should never fail.	2 years ago
Martin Atkins	1eaa18d60a	backendbase: IntValue ... With legacy helper/schema it's common to just type-assert whatever ResourceData.Get returns and trust that it'll always be valid. We can't achieve something quite that lazy with cty, but we can at least factor out the work of turning a value we already know is a number into an int64 value.	2 years ago
Martin Atkins	70537aab08	backendbase: ErrorAsDiagnostics ... The legacy helper/schema based Backend implementation expected the backend-specific code to return error and then wrapped it in diagnostics itself before returning. Backends using backendbase are supposed to return diagnostics directly themselves, but having to manually replace every error case with a higher-quality diagnostic message would get in the way of EOLing the legacy helper/schema implementation, and so this helper function is a pragmatic compromise to allow us to keep those updates purely mechanical for now and then improve diagnostics as a separate effort later.	2 years ago
Martin Atkins	46951b5b35	backendbase: Attribute lookup helpers ... Most of the remote state backends are currently written in terms of schema.ResourceData, lookup up attributes by path and possibly substituting default values when the attributes aren't explicitly set. These helpers aim to substitute for those common applications so that we can convert the existing backend logic more directly, without significantly increasing its complexity by suddenly moving the default value handling inline in their Configure functions.	2 years ago
Martin Atkins	df4cefbea9	backend: new "backendbase" helper package ... This is intended as a lighter-weight replacement for the Backend type in the legacy/helper/schema package, which indirectly pulls in our local copy of the entire legacy Terraform plugin SDK. This depends on the slightly-lower-level configschema package, which means that it's not quite as feature-rich as what it's replacing, but backends have relatively modest needs and so we can compensate with just some extra logic in their Configure functions, which will be considerably simpler than the huge bunch of legacy code we're currently depending on to get the same effects. In particular, configschema has no concept of "default values" for arguments, and so we'll need to deal with those in the Configure methods using imperative code, instead of declaratively. Nothing is using this yet, but in future commits we'll gradually convert all of the remote state backends to use this instead of the legacy system, and then remove the legacy system.	2 years ago