terraform

Commit Graph

Author	SHA1	Message	Date
Radek Simko	0fe906fa8c	make copyrightfix	3 months ago
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

4 Commits (add-missing-variable-loading)