This adds supports for "unmanaged" providers, or providers with process
lifecycles not controlled by Terraform. These providers are assumed to
be started before Terraform is launched, and are assumed to shut
themselves down after Terraform has finished running.
To do this, we must update the go-plugin dependency to v1.3.0, which
added support for the "test mode" plugin serving that powers all this.
As a side-effect of not needing to manage the process lifecycle anymore,
Terraform also no longer needs to worry about the provider's binary, as
it won't be used for anything anymore. Because of this, we can disable
the init behavior that concerns itself with downloading that provider's
binary, checking its version, and otherwise managing the binary.
This is all managed on a per-provider basis, so managed providers that
Terraform downloads, starts, and stops can be used in the same commands
as unmanaged providers. The TF_REATTACH_PROVIDERS environment variable
is added, and is a JSON encoding of the provider's address to the
information we need to connect to it.
This change enables two benefits: first, delve and other debuggers can
now be attached to provider server processes, and Terraform can connect.
This allows for attaching debuggers to provider processes, which before
was difficult to impossible. Second, it allows the SDK test framework to
host the provider in the same process as the test driver, while running
a production Terraform binary against the provider. This allows for Go's
built-in race detector and test coverage tooling to work as expected in
provider tests.
Unmanaged providers are expected to work in the exact same way as
managed providers, with one caveat: Terraform kills provider processes
and restarts them once per graph walk, meaning multiple times during
most Terraform CLI commands. As unmanaged providers can't be killed by
Terraform, and have no visibility into graph walks, unmanaged providers
are likely to have differences in how their global mutable state behaves
when compared to managed providers. Namely, unmanaged providers are
likely to retain global state when managed providers would have reset
it. Developers relying on global state should be aware of this.
* update vendored azure sdk
* vendor giovanni storage sdk
* Add giovanni clients
* go mod vendor
* Swap to new storage sdk
* workable tests
* update .go-version to 1.14.2
* Tests working minus SAS
* Add SAS Token support
* Update vendor
* Passing tests
* Add date randomizer
* Captalize RG
* Remove random bits
* Update client var name
Co-authored-by: kt <kt@katbyte.me>
This includes a new TargetAddrs field on both Run and RunCreateOptions
which we'll use to send resource addresses that were specified using
-target on the CLI command line when using the remote backend.
There were some unrelated upstream breaking changes compared to the last
version we had vendored, so this commit also includes some changes to the
backend/remote package to work with this new API, which now requires the
remote backend to be aware of the remote system's opaque workspace id.
* update github.com/aws/aws-sdk-go to v1.30.9
* deps: github.com/aws/aws-sdk-go@v1.30.12
Reference: https://github.com/hashicorp/terraform/issues/24710
Reference: https://github.com/hashicorp/terraform/issues/24741
Changes:
```
NOTES:
* backend/s3: Region validation now automatically supports the new `af-south-1` (Africa (Cape Town)) region. For AWS operations to work in the new region, the region must be explicitly enabled as outlined in the [AWS Documentation](https://docs.aws.amazon.com/general/latest/gr/rande-manage.html#rande-manage-enable). When the region is not enabled, the Terraform S3 Backend will return errors during credential validation (e.g. `error validating provider credentials: error calling sts:GetCallerIdentity: InvalidClientTokenId: The security token included in the request is invalid`).
ENHANCEMENTS:
* backend/s3: Support automatic region validation for `af-south-1`
```
Updated via:
```console
$ go get github.com/aws/aws-sdk-go@v1.30.12
$ go mod tidy
$ go mod vendor
```
Output from acceptance testing:
```console
$ TF_ACC=1 go test -v ./backend/remote-state/s3 | grep '^--- '
--- PASS: TestBackend_impl (0.00s)
--- PASS: TestBackendConfig (1.68s)
--- PASS: TestBackendConfig_invalidKey (0.00s)
--- PASS: TestBackendConfig_invalidSSECustomerKeyLength (0.00s)
--- PASS: TestBackendConfig_invalidSSECustomerKeyEncoding (0.00s)
--- PASS: TestBackendConfig_conflictingEncryptionSchema (0.00s)
--- PASS: TestBackend (15.07s)
--- PASS: TestBackendLocked (26.40s)
--- PASS: TestBackendSSECustomerKey (16.99s)
--- PASS: TestBackendExtraPaths (12.05s)
--- PASS: TestBackendPrefixInWorkspace (5.55s)
--- PASS: TestKeyEnv (45.07s)
--- PASS: TestRemoteClient_impl (0.00s)
--- PASS: TestRemoteClient (5.39s)
--- PASS: TestRemoteClientLocks (14.30s)
--- PASS: TestForceUnlock (20.08s)
--- PASS: TestRemoteClient_clientMD5 (16.43s)
--- PASS: TestRemoteClient_stateChecksum (24.58s)
```
Co-authored-by: Nicola Senno <nicola.senno@workday.com>
This fixes several bugs:
- `substr("abc", 0, 0)` would previously return `"abc"`, despite the
length argument being `0`. This has been changed to return an empty
string when length is zero.
- `ceil(1/0)` and `floor(1/0)` would previously return a large integer
value, rather than infinity. This has been fixed.
This library implements the user-specific directory layout specifications
for various platforms (XDG on Unix, "Known Folders" on Windows, etc).
We'll use this in a subsequent commit to add additional system-specific
search directories for provider plugins, and perhaps later on also
CLI configuration directories.
* add TencentCloud COS backend for remote state
* add vendor of dependence
* fixed error not handle and remove default value for prefix argument
* get appid from TF_COS_APPID environment variables
These are intended to make it easier to work with arbitrary data
structures whose shape might not be known statically, such as the result
of jsondecode(...) or yamldecode(...) of data from a separate system.
For example, in an object value which has attributes that may or may not
be set we can concisely provide a fallback value to use when the attribute
isn't set:
try(local.example.foo, "fallback-foo")
Using a "try to evaluate" model rather than explicit testing fits better
with the usual programming model of the Terraform language where values
are normally automatically converted to the necessary type where possible:
the given expression is subject to all of the same normal type conversions,
which avoids inadvertently creating a more restrictive evaluation model
as might happen if this were handled using checks like a hypothetical
isobject(...) function, etc.
This brings in the new HCL extension functions "try", "can", and
"convert", along with the underlying HCL and cty infrastructure that allow
them to work.
* deps: bump terraform-config-inspect library
* configs: parse `version` in new required_providers block
With the latest version of `terraform-config-inspect`, the
required_providers attribute can now be a string or an object with
attributes "source" and "version". This change allows parsing the
version constraint from the new object while ignoring any given source attribute.
This also includes an upgrade to cty v1.1.1 because HCL calls for it.
The changes in these two libraries are mainly to codepaths that don't
directly affect Terraform, but including this upgrade will cause some
small improvements to Terraform's error messages for type conversion
problems.
Previously we were using the experimental HCL 2 repository, but now we'll
shift over to the v2 import path within the main HCL repository as part of
actually releasing HCL 2.0 as stable.
This is a mechanical search/replace to the new import paths. It also
switches to the v2.0.0 release of HCL, which includes some new code that
Terraform didn't previously have but should not change any behavior that
matters for Terraform's purposes.
For the moment the experimental HCL2 repository is still an indirect
dependency via terraform-config-inspect, so it remains in our go.sum and
vendor directories for the moment. Because terraform-config-inspect uses
a much smaller subset of the HCL2 functionality, this does still manage
to prune the vendor directory a little. A subsequent release of
terraform-config-inspect should allow us to completely remove that old
repository in a future commit.
This new version includes Solaris support, the lack of which previously
caused us to disable readline-using features ("terraform console") on
Solaris builds.
Pam Selle