Commit Graph

6206 Commits

Author SHA1 Message Date
Pam Selle c6ab9b1553
Merge pull request #26938 from hashicorp/pselle/remove-vendor-provisioners
Remove vendor provisioners
2020-12-02 11:48:40 -05:00
Martin Atkins 832bd5f41f website: Initial docs for the provider_sensitive_attrs experiment
This is under a heading "Sensitive Resource Attributes" on the assumption
that if we later stabilize this feature then this heading will live on
with some different content that describes the propagation of sensitive
values from resource attributes, rather than describing the experiment.
2020-12-02 08:06:08 -08:00
Pam Selle 67fe3bfd69
Merge pull request #27058 from hashicorp/paultyng-patch-1
Add comments about this URL being linked to in the CLI
2020-12-02 09:42:16 -05:00
Nick Fagerlund 83ebb9b178 website: Add big whitespace separators to recovery landing pages
The resources, expressions, and modules pages were all split into smaller, more
navigable pages, but the old URLs had accumulated a large number of deep links
to their section headers. To help people recover when they click an old link, we
converted those old URLs to landing pages, which preserve all of the old in-page
anchors and point readers to the appropriate new destinations.

However, because the new link-to-new-page sections are so small, it was kind of
hard to tell which section you had clicked into! Especially if you were near the
bottom of the page and the browser wasn't able to position the desired section
at the very top of the window.

This commit aims to improve that by putting one full screen of whitespace in
between every linkable section on these landing pages. Yes, it's a hack, but
you're meant to only view these pages for three seconds or so before moving on
to the place you wanted to be, and this should help dispel any confusion about
which place that is.
2020-12-01 15:38:25 -08:00
Nick Fagerlund d5950b7fd2 website: link to dependency lock file tutorial 2020-12-01 15:20:14 -08:00
Nick Fagerlund 652b48bb49 website: link to sensitive variables tutorial 2020-12-01 15:16:16 -08:00
Nick Fagerlund a1e73ade61 website: link to expressions tutorial where applicable
This tutorial uses references to local values, conditional expressions,
and splat expressions, so I've added it to those pages as well as the
expressions overview.
2020-12-01 13:12:12 -08:00
Nick Fagerlund 5895472c93 website: link to functions tutorial where applicable 2020-12-01 13:10:05 -08:00
Paul Tyng c4b46a5c98
Update signing.html.md 2020-11-30 16:13:49 -05:00
Martin Atkins 111825da45 website: More words about "terraform fmt"
We've historically made statements like this in response to requests for
more customization to the "terraform fmt" behavior, but the documentation
itself was somewhat vague about the intended goals of this command.

This is an attempt to be more explicit that consistency between codebases
is the primary goal of this command, and that the examples in the
Terraform documentation are our main guide for what is "idiomatic style"
when adding additional rules over time.

Nothing here is intended to be new policy, but instead as codifying
positions we've taken elsewhere in the past in the hope of allowing users
to decide how (and whether) they wish to make use of this tool.
2020-11-25 08:03:37 -08:00
Alisdair McDiarmid 42437482e5
Merge pull request #26947 from hashicorp/alisdair/backend-validate-remote-backend-terraform-version
backend: Validate remote backend Terraform version
2020-11-20 13:50:05 -05:00
Alisdair McDiarmid c5c1f31db3 backend: Validate remote backend Terraform version
When using the enhanced remote backend, a subset of all Terraform
operations are supported. Of these, only plan and apply can be executed
on the remote infrastructure (e.g. Terraform Cloud). Other operations
run locally and use the remote backend for state storage.

This causes problems when the local version of Terraform does not match
the configured version from the remote workspace. If the two versions
are incompatible, an `import` or `state mv` operation can cause the
remote workspace to be unusable until a manual fix is applied.

To prevent this from happening accidentally, this commit introduces a
check that the local Terraform version and the configured remote
workspace Terraform version are compatible. This check is skipped for
commands which do not write state, and can also be disabled by the use
of a new command-line flag, `-ignore-remote-version`.

Terraform version compatibility is defined as:

- For all releases before 0.14.0, local must exactly equal remote, as
  two different versions cannot share state;
- 0.14.0 to 1.0.x are compatible, as we will not change the state
  version number until at least Terraform 1.1.0;
- Versions after 1.1.0 must have the same major and minor versions, as
  we will not change the state version number in a patch release.

If the two versions are incompatible, a diagnostic is displayed,
advising that the error can be suppressed with `-ignore-remote-version`.
When this flag is used, the diagnostic is still displayed, but as a
warning instead of an error.

Commands which will not write state can assert this fact by calling the
helper `meta.ignoreRemoteBackendVersionConflict`, which will disable the
checks. Those which can write state should instead call the helper
`meta.remoteBackendVersionCheck`, which will return diagnostics for
display.

In addition to these explicit paths for managing the version check, we
have an implicit check in the remote backend's state manager
initialization method. Both of the above helpers will disable this
check. This fallback is in place to ensure that future code paths which
access state cannot accidentally skip the remote version check.
2020-11-19 13:19:40 -05:00
Nick Fagerlund 2014e8ef64 website: Remove registry docs (adopted into terraform-website)
The Registry is a web service whose behavior isn't directly tied to Terraform
core's release cycle; therefore, its docs should be decoupled from that release
cycle as well.

https://github.com/hashicorp/terraform-website/pull/1517 adopts the registry
docs into hashicorp/terraform-website, which already hosts several other
corpuses of documentation that aren't tied to Terraform core's version (like
Terraform Cloud, Terraform Enterprise, and Extending Terraform). Once that PR is
merged, we should remove the registry docs from this repository to avoid
confusing anyone.
2020-11-18 11:12:35 -08:00
Nick Fagerlund db82b80c9d website: Fix a random typo in azurerm backend 2020-11-18 10:47:52 -08:00
Nick Fagerlund f2f47c3c9f
website: Fix title of `terraform providers lock` page (#26956)
Probably a copy/paste error.

Co-authored-by: Petros Kolyvas <petros@hashicorp.com>
2020-11-18 10:45:27 -08:00
Martin Atkins af3f78975e website: Fix confusing example for local-exec provisioner
The local-exec provisioner documentation includes an example which refers
to an attribute of the current resource using its full traversal path,
rather than using "self" as we typically expect.

Due to some coincidences in how Terraform builds the dependency graph,
referring to the resource in this way happens to work when the resource
has only a single instance (the graph builder just skips that
self-referential dependency edge), but it fails if the user later tries
to add "count" or "for_each" to the resource, because at that point all
of the instances become dependent on one another, which creates a
dependency cycle.

Using "self" to access the current instance attributes is the usual
approach, so I've updated the documentation to show that.
2020-11-18 08:04:41 -08:00
Martin Atkins 9f45a73581 website: Reword confusing statement about module sources in TFE
As written previously this seemed to suggest using "app.terraform.io" (the
"hostname you use to access the Terraform Cloud application) to access a
private registry in Terraform Enterprise, but that isn't true and I assume
isn't what was intended.

Instead, the hostname for a Terraform Enterprise instance is the hostname
where the Terraform Enterprise application is running, which is both the
hostname where users would find its web UI and the hostname they'd use
to configure the "remote" backend for remote operations and state storage.
2020-11-18 08:04:10 -08:00
Martin Atkins df47da1f8e website: "coalesce" function unifies its argument types
In order to be able to predict a result type even if arguments are not yet
known, coalesce requires all of its arguments to be of the same type. Our
usual automatic conversion rules mean that in some cases the result is
a silent type conversion rather than an explicit error, so we'll at least
document that so that folks who encounter it can understand what is
causing the likely-surprising behavior.

If we were building this function over again today I expect we'd make it
always return an error under type mismatch, but to do so now would be a
breaking change and the potential cost of that seems too high for
something that doesn't seem to arise incredibly often in practice.
2020-11-18 08:03:37 -08:00
Nick Fagerlund 2bfec75bbf website: Update all links to {expressions,modules,resources}.html
...as well as to the standard module structure section in module development.
2020-11-17 16:30:51 -08:00
Nick Fagerlund 209541aaf0 website: Break up main Modules and Module Development pages
This one is a lot like the previous two commits, but slightly more complex:

- Only adding one new meta-argument page, for `providers`; otherwise, it just
  re-uses the dual-purpose pages I made in the resources commit.

- About that `providers` argument: The stuff that was relevant to consumers of a
  module went in that meta-argument page, but there was also a huge deep dive on
  how the _author_ of a re-usable module should handle provider configurations
  in cases where inheriting the default providers isn't sufficient. THAT, I
  moved into a new page in the module development section. (For the consumer of
  a module, this should all be an implementation detail; the module README
  should tell you which aliased providers you need to configure and pass, and
  then you just do it, without worrying about proxy configuration blocks etc.)

- The "standard module structure" recommendations in the main module development
  page gets a page of its own, to make it more prominent and discoverable.

- Same deal with using the old URL as a landing page, at least for the main
  module calls page. It didn't seem necessary for the module development page.
2020-11-17 16:30:51 -08:00
Nick Fagerlund 6e2f5eb0be website: Break up Resources page into smaller chunks
- Resource behavior gets its own page.
- Meta-arguments all get their own pages.
- Stuff about resource syntax itself gets a page.

In the process of breaking the meta-arguments out into their own pages, I
revised them (with the exception of `provider`) so that they apply to both
resources and modules.

Like with Expressions, this commit repurposes the old resources.html URL as a
landing page for old links.
2020-11-17 16:30:51 -08:00
Nick Fagerlund a446ecb7b7 website: Break up Expressions page into smaller chunks
This commit converts the previous URL for this content to a landing page, which
captures all of the previous in-page anchors and directs readers to the new home
for each section.
2020-11-17 16:30:51 -08:00
Martin Atkins 6bb9fa7341 website: Document alternatives to terraform_remote_state
For some time now we've been recommending explicitly passing data between
configurations using separate resource types and data sources, rather than
always using terraform_remote_state, for reasons including reducing
coupling between subsystems and allowing a configuration's state snapshots
to be under restrictive access controls.

However, those recommendations have so far not appeared directly in the
documentation for terraform_remote_state, and have instead just been
alluded to elsewhere in the documentation when discussing ways to pass
data between configurations.

This change, then, is an attempt to be clear and explicit about the
recommendation and to give a variety of specific examples of how to
implement it. The terraform_remote_state data source page is admittedly
not the most obvious place in the information architecture to put a set
of alternatives to it, but it does appear that this documentation page is
where people most commonly end up when researching options in this area
and so I've put this here in an attempt to "meet people where they are".

Possibly in a future documentation reorganization we might have an
separate page specifically about sharing data between configurations, but
we don't currently have time to do that bigger reorganization. If we do so
later, the content on this page could potentially be replaced with a
summary of the recommendation and a link to another place for the details,
but the goal here is to make this information visible in the existing
location people look for it, rather than blocking until there's a better
place for it to live.

This also includes a small amount of editing of some existing content on
the page to use terminology and style more similar to how our main
configuration language documentation is written,.
2020-11-17 09:41:54 -08:00
Pam Selle e39e0e3d04 Remove vendor provisioners and add fmt Make target
Remove chef, habitat, puppet, and salt-masterless provsioners,
which follows their deprecation. Update the documentatin for these
provisioners to clarify that they have been removed from later versions
of Terraform. Adds the fmt Make target back and updates fmtcheck script
for correctness.
2020-11-17 11:22:03 -05:00
Kristin Laemmert 79fd81775e
website/intro: remove outdated examples section (#26932) 2020-11-16 14:05:17 -05:00
Martin Atkins 7ccaee1018 website: Fix inconsistencies in the registry protocol page
Some hasty, incorrect merge conflict fixing caused this page to have a
strange mix of terminology between "system" and "provider". Along with
that, there were also several editorial errors caused by text on this
page having originally been derived from the provider registry
documentation.

This documentation will now consistently talk about being a module
registry protocol rather than a provider registry protocol, and it will
consistently use the term "system" as a generic term for the final part
of the module source address, aside from noting that there is an optional
convention to name it after the "type" part of an official provider when
possible.
2020-11-16 10:06:27 -08:00
Andrew Fitzgerald 8c82b3f6a0 Remove 'system' references from module registry protocol docs. 2020-11-16 10:01:03 -08:00
TEDmk 8195a99529
Add a missing new line
The missing new line doesn't permit the code block to show up.
2020-11-16 16:08:55 +01:00
Martin Atkins cec4578005 lang/funcs: Experimental "defaults" function
This is a new part of the existing module_variable_optional_attrs
experiment, because it's intended to complement the ability to declare
an input variable whose type constraint is an object type with optional
attributes. Module authors can use this to replace null values (that were
either explicitly set or implied by attribute omission) with other
non-null values of the same type.

This function is a bit more type-fussy than our functions typically are
because it's intended for use primarily with input variables that have
fully-specified type constraints, and thus it uses that type information
to help inform how the defaults data structure should be interpreted.

Other uses of this function will probably be harder today because it takes
a lot of extra annotation to build a value of a specific type if it isn't
passing through a variable type constraint. Perhaps later language
features for more general type conversion will make this more applicable,
but for now the more general form of this problem is better solved other
ways.
2020-11-13 17:27:20 -08:00
Pam Selle 9f5f5adc0d
Merge pull request #26799 from flatiron32/patch-1
Remove redundant Local Named Values section
2020-11-13 11:39:33 -05:00
Kent 'picat' Gruber 63cc597bc3
Fix grammar
Co-authored-by: Pam Selle <pam@hashicorp.com>
2020-11-13 11:28:13 -05:00
Kent 'picat' Gruber 20026819dd Remove path-style specific wording in module sources doc
Follow up on wording added in https://github.com/hashicorp/terraform/pull/20377
2020-11-13 11:15:06 -05:00
hhofs 5b99a56fde
communicator/ssh: Add support for Windows targets (#26865) 2020-11-12 10:00:48 -05:00
Nick Fagerlund 5e18e44037
Merge pull request #26723 from hashicorp/oct20_language_and_cli_docs
website: TF-153: Split core Terraform docs into "Language" and "CLI"
2020-11-11 19:31:05 -08:00
Nick Fagerlund 2c02233a16 website: Add new "glue"/overview pages for CLI and language docs
The new nav structure demanded a few new pages that give context about a feature
or workflow. In a few cases, they take text from an existing page.

Co-authored-by: Tu Nguyen <im2nguyen@users.noreply.github.com>
Co-authored-by: Judith Malnick <judith.patudith@gmail.com>
2020-11-11 19:13:23 -08:00
Nick Fagerlund d01faf1cb2 website: Remove unused "island" nav sidebars
The pages that used to use these isolated navs have been adopted into the new
unified nav sidebars.
2020-11-11 19:11:29 -08:00
Nick Fagerlund 8b87318b35 website: Add new Language sidebar, repurpose docs.erb as CLI sidebar
We're splitting the current Terraform CLI docs into two top-level categories,
and these are the new nav sidebars for those sections.

As of this commit, they refer to some new "glue" pages that don't exist yet.
2020-11-11 19:11:29 -08:00
Martin Atkins 80b13307e8 website: Initial docs about the APT/Yum repositories
The HashiCorp engineering services team has set up APT and Yum
repositories as alternative installation methods for various HashiCorp
products, now including Terraform.

We don't really have a great place to talk about these in our current
website structure. There is a longer-term plan to revamp the downloads
page to include other options, but we are already getting lots of
questions about how to use these repositories and so my goal here is to
publish at least a first pass of documentation, linked from the Downloads
page sidebar as a placeholder for now, so we'll have somewhere to refer to
when answering such questions.

My intent is that even once we have a revamped Downloads page that
mentions these options more clearly, we'll still need to link out to
another page to talk about various details, and so the two new URLs this
creates would be the home of that content, even if we rewrite the specific
prose here to work better in the context of the new Downloads page.
2020-11-11 09:50:22 -08:00
Andor Markus 9d3143381b
Update delete.html.md (#26874) 2020-11-11 10:14:54 -04:00
Justin Campbell 7c98be92c2
website: Add Registry docs for webhooks (#26870) 2020-11-10 12:33:26 -05:00
Robin Norwood ec7d9c85ac Update link to new varibles tutorial 2020-11-09 11:52:28 -08:00
Upo 3b9c5e5bbb
backend/gcs: remove deprecated "path" config argument (#26841) 2020-11-06 16:35:40 -05:00
Alisdair McDiarmid 3680bc521a website: Update output command docs
The example configuration now uses Terraform 0.12+ syntax, and the
output examples are up to date with the current text UI. We also add an
explicit recommendation to use the `-json` option for a consistent and
stable output format, for use in automation.
2020-11-06 15:10:31 -05:00
Upo 4ccc63d79d
backend: Add service account impersonation to GCS Backend and update the docs (#26700) 2020-11-06 09:06:07 -05:00
Joshua Mendoza 27e31e1160
Update lookup.html.md (#26835)
Typo in introductory paragraph.
2020-11-06 09:58:33 -04:00
Martin Atkins ae3c0c6a4a lang/funcs: Remove the deprecated "list" and "map" functions
Prior to Terraform 0.12 these two functions were the only way to construct
literal lists and maps (respectively) in HIL expressions. Terraform 0.12,
by switching to HCL 2, introduced first-class syntax for constructing
tuple and object values, which can then be converted into list and map
values using the tolist and tomap type conversion functions.

We marked both of these functions as deprecated in the Terraform v0.12
release and have since then mentioned in the docs that they will be
removed in a future Terraform version. The "terraform 0.12upgrade" tool
from Terraform v0.12 also included a rule to automatically rewrite uses
of these functions into equivalent new syntax.

The main motivation for removing these now is just to get this change made
prior to Terraform 1.0. as we'll be doing with various other deprecations.
However, a specific reason for these two functions in particular is that
their existence is what caused us to invent the idea of a "type expression"
as a distinct kind of expression in Terraform v0.12, and so removing them
now would allow potentially  unifying type expressions with value
expressions in a future release.

We do not have any current specific plans to make that change, but one
potential motivation for doing so would be to take another attempt at a
generalized "convert" function which takes a type as one of its arguments.
Our previous attempt to implement such a function was foiled by the fact
that Terraform's expression validator doesn't have any way to know to
treat one argument of a particular function as special, and so it was
generating incorrect error messages. We won't necessarily do that, but
having these "list" and "map" functions out of the way leaves the option
open.
2020-11-04 17:05:59 -08:00
Radek Simko eddcc4d80c
docs: Fix typo (provider arg in data source) (#26802) 2020-11-04 09:55:15 -04:00
Jacob Tomaw 3f9abbc30d
Remove redundant Local Named Values section
The second Local Named Values has a subset of the information the first one has and adds nothing to the documentation other than confusion.
2020-11-03 08:09:12 -05:00
Tej-Singh-Rana 832918c65b
website: fixed spelling error (#26758) 2020-11-02 11:15:44 -08:00
timvandamme fbf267fbfd
website: for_each doesn't implicitly convert to set (#26450)
The documentation states that an explicit type conversion to set is needed, but it does not say why implicit type conversion does not work. 

Co-authored-by: Nick Fagerlund <nick@hashicorp.com>
2020-11-02 11:13:51 -08:00