This project is mirrored from https://:*****@github.com/hashicorp/terraform.git.
Pull mirroring failed .
Repository mirroring has been paused due to too many failed attempts. It can be resumed by a project maintainer.
Repository mirroring has been paused due to too many failed attempts. It can be resumed by a project maintainer.
- 02 Feb, 2019 1 commit
-
-
Nick Fagerlund authored
This is a non-working commit, because a bunch of links (including the sidebar nav) are broken. Using a transition commit like this makes it easier to see the changes necessary to get this content woven into the site.
-
- 01 Feb, 2019 1 commit
-
-
Nick Fagerlund authored
-
- 25 Jan, 2019 1 commit
-
-
Martin Atkins authored
In prior versions, we recommended using hash functions in conjunction with the file function as an idiom for detecting changes to upstream blobs without fetching and comparing the whole blob. That approach relied on us being able to return raw binary data from file(...). Since Terraform strings pass through intermediate representations that are not binary-safe (e.g. the JSON state), there was a risk of string corruption in prior versions which we have avoided for 0.12 by requiring that file(...) be used only with UTF-8 text files. The specific case of returning a string and immediately passing it into another function was not actually subject to that corruption risk, since the HIL interpreter would just pass the string through verbatim, but this is still now forbidden as a result of the stricter handling of file(...). To avoid breaking these use-cases, here we introduce variants of the hash functions a with "file" prefix that take a filename for a disk file to hash rather than hashing the given string directly. The configuration upgrade tool also now includes a rule to detect the documented idiom and rewrite it into a single function call for one of these new functions. This does cause a bit of function sprawl, but that seems preferable to introducing more complex rules for when file(...) can and cannot read binary files, making the behavior of these various functions easier to understand in isolation.
-
- 23 Jan, 2019 1 commit
-
-
Tom Harvey authored
-
- 17 Jan, 2019 1 commit
-
-
Martin Atkins authored
It's not normally necessary to make explicit type conversions in Terraform because the language implicitly converts as necessary, but explicit conversions are useful in a few specialized cases: - When defining output values for a reusable module, it may be desirable to force a "cleaner" output type than would naturally arise from a computation, such as forcing a string containing digits into a number. - Our 0.12upgrade mechanism will use some of these to replace use of the undocumented, hidden type conversion functions in HIL, and force particular type interpretations in some tricky cases. - We've found that type conversion functions can be useful as _temporary_ workarounds for bugs in Terraform and in providers where implicit type conversion isn't working correctly or a type constraint isn't specified precisely enough for the automatic conversion behavior. These all follow the same convention of being named "to" followed by a short type name. Since we've had a long-standing convention of running all the words together in lowercase in function names, we stick to that here even though some of these names are quite strange, because these should be rarely-used functions anyway.
-
- 16 Jan, 2019 2 commits
-
-
Martin Atkins authored
The sethaselement, setintersection, and setunion functions are defined in the cty stdlib. Making them available in Terraform will make it easier to work with sets, and complement the currently-Terraform-specific setproduct function. In the long run setproduct should probably move into the cty stdlib too, but since it was submitted as a Terraform function originally we'll leave it here now for simplicity's sake and reorganize later.
-
Martin Atkins authored
In our new world it produces either a set of a tuple type or a list of a tuple type, depending on the given argument types. The resulting collection's element tuple type is decided by the element types of the given collections, allowing type information to propagate even if unknown values are present.
-
- 15 Jan, 2019 1 commit
-
-
Sander van Harmelen authored
-
- 12 Jan, 2019 1 commit
-
-
Nick Fagerlund authored
This document was previously copied to the "Extending Terraform" section (in the terraform-website repo), and the old URL was redirected so that the copy in /guides can no longer be reached on the website. But the old copy of the file remained, and now it runs the risk of confusing contributors, since the copy in terraform-website/.../docs/extend is the more up-to-date version.
-
- 09 Jan, 2019 6 commits
-
-
Tom Harvey authored
Adding the AzureAD entry to the providers page
-
cgriggs01 authored
-
cgriggs01 authored
-
cgriggs01 authored
-
Brian Flad authored
The AWS Go SDK automatically provides a default request retryer with exponential backoff that is invoked via setting `MaxRetries` or leaving it `nil` will default to 3. The terraform-aws-provider `config.Client()` sets `MaxRetries` to 0 unless explicitly configured above 0. Previously, we were not overriding this behavior by setting the configuration and therefore not invoking the default request retryer. The default retryer already handles HTTP error codes above 500, including S3's InternalError response, so the extraneous handling can be removed. This will also start automatically retrying many additional cases, such as temporary networking issues or other retryable AWS service responses. Changes: * s3/backend: Add `max_retries` argument * s3/backend: Enhance S3 NoSuchBucket error to include additional information
-
Kristin Laemmert authored
A few minor fixes and cleanups as a result of said tests. Hooray for eventual consistency!
-
- 07 Jan, 2019 1 commit
-
-
Martin Atkins authored
We missed this one on a previous pass of bringing in most of the cty stdlib functions. This will resolve #17625 by allowing conversion from Terraform's conventional RFC 3339 timestamps into various other formats.
-
- 21 Dec, 2018 1 commit
-
-
Martin Atkins authored
This function is similar to the template_file data source offered by the template provider, but having it built in to the language makes it more convenient to use, allowing templates to be rendered from files anywhere an inline template would normally be allowed: user_data = templatefile("${path.module}/userdata.tmpl", { hostname = format("petserver%02d", count.index) }) Unlike the template_file data source, this function allows values of any type in its variables map, passing them through verbatim to the template. Its tighter integration with Terraform also allows it to return better error messages with source location information from the template itself. The template_file data source was originally created to work around the fact that HIL didn't have any support for map values at the time, and even once map support was added it wasn't very usable. With HCL2 expressions, there's little reason left to use a data source to render a template; the only remaining reason left to use template_file is to render a template that is constructed dynamically during the Terraform run, which is a very rare need.
-
- 20 Dec, 2018 5 commits
-
-
Nick Fagerlund authored
-
Nick Fagerlund authored
-
Nick Fagerlund authored
This commit is a wide-ranging set of edits to the pages under /docs/configuration. Among other things, it - Separates style conventions out into their own page. - Separates type constraints and conversion info into their own page. - Conflates similar complex types a little more freely, since the distinction is only relevant when restricting inputs for a reusable module or resource. - Clarifies several concepts that confused me during edits.
-
cgriggs01 authored
-
cgriggs01 authored
-
- 19 Dec, 2018 1 commit
-
-
cgriggs01 authored
-
- 14 Dec, 2018 1 commit
-
-
Sander van Harmelen authored
-
- 10 Dec, 2018 2 commits
-
-
Tom Harvey authored
* Upgrading to 2.0.0 of github.com/hashicorp/go-azure-helpers * Support for authenticating using Azure CLI * backend/azurerm: support for authenticating using the Azure CLI
-
cgriggs01 authored
-
- 07 Dec, 2018 1 commit
-
-
Brian Flad authored
This change enables a few related use cases: * AWS has partitions outside Commercial, GovCloud (US), and China, which are the only endpoints automatically handled by the AWS Go SDK. DynamoDB locking and credential verification can not currently be enabled in those regions. * Allows usage of any DynamoDB-compatible API for state locking * Allows usage of any IAM/STS-compatible API for credential verification
-
- 05 Dec, 2018 2 commits
-
-
cgriggs01 authored
-
Alex Gottschalk authored
"Later this summer" is long-gone.
-
- 29 Nov, 2018 1 commit
-
-
Chris Griggs authored
-
- 28 Nov, 2018 2 commits
-
-
cgriggs01 authored
-
Daniel Schroeder authored
-
- 26 Nov, 2018 3 commits
-
-
cgriggs01 authored
-
Tom Harvey authored
* backend/azurerm: removing the `arm_` prefix from keys * removing the deprecated fields test because the deprecation makes it fail * authentication: support for custom resource manager endpoints * Adding debug prefixes to the log statements
-
Tom Harvey authored
* backend/azurerm: removing the `arm_` prefix from keys * removing the deprecated fields test because the deprecation makes it fail
-
- 22 Nov, 2018 2 commits
-
-
Tom Harvey authored
* adding acceptance tests for msi auth * including the resource group name in the tests * backend/azurerm: support for authenticating using a SAS Token * resolving merge conflicts * moving the defer to prior to the error
-
Tom Harvey authored
* backend/azurerm: support for authenticating via msi * adding acceptance tests for msi auth * including the resource group name in the tests * support for using the test client via msi
-
- 21 Nov, 2018 2 commits
-
-
Tom Harvey authored
* vendor updates - updating to v21.3.0 of github.com/Azure/azure-sdk-for-go - updating to v10.15.4 of github.com/Azure/go-autorest - vendoring github.com/hashicorp/go-azure-helpers @ 0.1.1 * backend/azurerm: refactoring to use the new auth package - refactoring the backend to use a shared client via the new auth package - adding tests covering both Service Principal and Access Key auth - support for authenticating using a proxy - rewriting the backend documentation to include examples of both authentication types * switching to use the build-in logging function * documenting it's also possible to retrieve the access key from an env var
-
Nick Fagerlund authored
...and one other reference to the application data directory. Context: https://docs.microsoft.com/en-us/windows/desktop/shell/knownfolderid#folderid_roamingappdata In newer Windows versions, the folder accessible as `%APPDATA%` (and via various APIs) is actually at something like "documents and settings\user\application data\roaming", while earlier versions omit the "\roaming" part of the path. This means you can confuse people by referring to the "application data" directory by its human name, because "roaming" is the real application data directory, but it looks like a subdirectory of "application data". Thus, it's less confusing to just use the `%APPDATA%` variable, with the added benefit that you can copy and paste the path and it'll just work in most places.
-
- 16 Nov, 2018 1 commit
-
-
cgriggs01 authored
-