4 Commits (fc8a76a2a3a2ce0d318cdb2e6f3f76ebbc6b28ac)

Author	SHA1	Message	Date
Pam Selle	bd70bc63eb	Add provider sensitivity propagation experiment ... Rolls back marking attributes providers mark as sensitive to an `experiment` and adds associated docs and adjustments to the upgrade guide.	6 years ago
Pam Selle	7924117acc	Add note to upgrade guide about provider sensitivity (#26643) ... * Add note to upgrade guide about provider sensitivity Now that sensitivity follows attributes providers mark as sensitive, add this note to the upgrade guide. Co-authored-by: Alisdair McDiarmid <alisdair@users.noreply.github.com>	6 years ago
Martin Atkins	e70ab09bf1	command: new cache directory .terraform/providers for providers ... Terraform v0.10 introduced .terraform/plugins as a cache directory for automatically-installed plugins, Terraform v0.13 later reorganized the directory structure inside but retained its purpose as a cache. The local cache used to also serve as a record of specifically which packages were selected in a particular working directory, with the intent that a second run of "terraform init" would always select the same packages again. That meant that in some sense it behaved a bit like a local filesystem mirror directory, even though that wasn't its intended purpose. Due to some unfortunate miscommunications, somewhere a long the line we published some documentation that _recommended_ using the cache directory as if it were a filesystem mirror directory when working with Terraform Cloud. That was really only working as an accident of implementation details, and Terraform v0.14 is now going to break that because the source of record for the currently-selected provider versions is now the public-facing dependency lock file rather than the contents of an existing local cache directory on disk. After some consideration of how to move forward here, this commit implements a compromise that tries to avoid silently doing anything surprising while still giving useful guidance to folks who were previously using the unsupported strategy. Specifically: - The local cache directory will now be .terraform/providers rather than .terraform/plugins, because .terraform/plugins is effectively "poisoned" by the incorrect usage that we can't reliably distinguish from prior version correct usage. - The .terraform/plugins directory is now the "legacy cache directory". It is intentionally _not_ now a filesystem mirror directory, because that would risk incorrectly interpreting providers automatically installed by Terraform v0.13 as if they were a local mirror, and thus upgrades and checksum fetches from the origin registry would be blocked. - Because of the previous two points, someone who _was_ trying to use the legacy cache directory as a filesystem mirror would see installation fail for any providers they manually added to the legacy directory. To avoid leaving that user stumped as to what went wrong, there's a heuristic for the case where a non-official provider fails installation and yet we can see it in the legacy cache directory. If that heuristic matches then we'll produce a warning message hinting to move the provider under the terraform.d/plugins directory, which is a _correct_ location for "bundled" provider plugins that belong only to a single configuration (as opposed to being installed globally on a system). This does unfortunately mean that anyone who was following the incorrectly-documented pattern will now encounter an error (and the aforementioned warning hint) after upgrading to Terraform v0.14. This seems like the safest compromise because Terraform can't automatically infer the intent of files it finds in .terraform/plugins in order to decide automatically how best to handle them. The internals of the .terraform directory are always considered implementation detail for a particular Terraform version and so switching to a new directory for the _actual_ cache directory fits within our usual set of guarantees, though it's definitely non-ideal in isolation but okay when taken in the broader context of this problem, where the alternative would be silent misbehavior when upgrading.	6 years ago
Martin Atkins	e1aff2bab0	website: First draft of v0.14 upgrade guide ... The upgrade requirements for this release are considerably more modest than for Terraform v0.13, so this time we just have some notes about a few changes in behavior that may be impactful to some users. This first pass is intended to be included as part of a forthcoming beta testers' guide as we begin the v0.14 beta testing period. We will make further changes to this upgrade guide based on feedback from those who participate in the beta process. Note that this upgrade guide is not intended as release marketing material and so its presentation is focused on addressing concerns users might encounter while upgrading. We'll share highlights from the release in other contexts, such as the changelog and in the product blog.	6 years ago