Commit Graph

166 Commits

Author SHA1 Message Date
Kristin Laemmert 583859e510
commands: `terraform add` (#28874)
* command: new command, terraform add, generates resource templates

terraform add ADDRESS generates a resource configuration template with all required (and optionally optional) attributes set to null. This can optionally also pre-populate nonsesitive attributes with values from an existing resource of the same type in state (sensitive vals will be populated with null and a comment indicating sensitivity)

* website: terraform add documentation
2021-06-17 12:08:37 -04:00
Kristin Laemmert 9ca3cb4233
website/docs: move type func docs to a useful location (#28940)
* website/docs: move type func docs to a useful location

* docs don't exist if you don't put them in the index (again)
2021-06-14 08:54:27 -04:00
Martin Atkins 07aa07f5b9 website: First Draft of Upgrade Guide 2021-06-07 17:23:39 -07:00
Martin Atkins 035d1648e4 website: Link to the v0.15 upgrade guide
Unfortunately it seems that this link got lost in a merge conflict when
we did the big nav refactor earlier in the v0.15 cycle, so here we'll
retoractively add it to the new location for upgrade guide nav, in the
language layout rather than the downloads layout.
2021-04-15 10:17:02 -07:00
Martin Atkins 140c613ae8 lang/funcs: "one" function
In the Terraform language we typically use lists of zero or one values in
some sense interchangably with single values that might be null, because
various Terraform language constructs are designed to work with
collections rather than with nullable values.

In Terraform v0.12 we made the splat operator [*] have a "special power"
of concisely converting from a possibly-null single value into a
zero-or-one list as a way to make that common operation more concise.

In a sense this "one" function is the opposite operation to that special
power: it goes from a zero-or-one collection (list, set, or tuple) to a
possibly-null single value.

This is a concise alternative to the following clunky conditional
expression, with the additional benefit that the following expression is
also not viable for set values, and it also properly handles the case
where there's unexpectedly more than one value:

    length(var.foo) != 0 ? var.foo[0] : null

Instead, we can write:

    one(var.foo)

As with the splat operator, this is a tricky tradeoff because it could be
argued that it's not something that'd be immediately intuitive to someone
unfamiliar with Terraform. However, I think that's justified given how
often zero-or-one collections arise in typical Terraform configurations.
Unlike the splat operator, it should at least be easier to search for its
name and find its documentation the first time you see it in a
configuration.

My expectation that this will become a common pattern is also my
justification for giving it a short, concise name. Arguably it could be
better named something like "oneornull", but that's a pretty clunky name
and I'm not convinced it really adds any clarity for someone who isn't
already familiar with it.
2021-04-12 15:32:03 -07:00
Martin Atkins 89b2405080 lang/funcs: "sensitive" and "nonsensitive" functions
These aim to allow hinting to Terraform about situations where it's not
able to automatically infer value sensitivity.

"nonsensitive" is for situations where Terraform's behavior is too
conservative, such as when a new value is derived from a sensitive value
in such a way that all of the sensitive content is removed.

"sensitive", on the other hand, is for situations where Terraform can't
otherwise infer that a value is sensitive. These situations should be
pretty rare in a module that's making effective use of sensitive input
variables and output values, but the documentation shows one example of
an uncommon situation where a more direct hint via this function would
be needed.

Both of these functions are aimed at only occasional use in unusual
situations. They are here for reasons of pragmatism, not because we
expect them to be used routinely or recommend their use.
2021-03-16 16:26:22 -07:00
Martin Atkins 8d37a70987 website: Initial docs for the module integration testing experiment
Since this is still at an early phase and likely to change significantly
in future iterations, rather than attempting to guess on a suitable final
location for documenting the testing feature I've instead taken the
unusual approach of adding a new page that is explicitly about the
experiment. My expectation is that once we conclude the experiment we'll
replace this new page with a stub that just explains that there was once
an experiment and then links to whatever final feature unfolded from the
research.

The URL for this page is hard-coded into the warning message in the
"terraform test" command, so as we continue to evolve this feature in
future releases we'll need to update the callout note on the page about
which Terraform CLI version it's currently talking about, so users of
older versions can clearly see when they'd need to upgrade in order to
participate in a later incarnation of the experiment.
2021-02-22 14:21:45 -08:00
Nick Fagerlund 01a449e335 website: CLI: Update sidebar nav with new URLs 2021-01-22 12:22:21 -08:00
Nick Fagerlund 7a8dd326c6 website: Language: Update links to moved pages 2021-01-22 12:22:21 -08:00
Nick Fagerlund b71786d9de website: Language: Update sidebar nav with new URLs
The files aren't moved as of this commit, but this serves as a map for the
subsequent changes.
2021-01-22 12:22:20 -08:00
Nick Fagerlund 66f2c82d33 website: Add version command to sidebar nav and to plugins overview page 2021-01-12 14:40:45 -08:00
Nick Fagerlund ccb205896d website: Fix alphabetical ordering of commands 2021-01-12 14:34:45 -08:00
Nick Fagerlund 5ceb8b2b98 website: Adopt `terraform_remote_state` into language docs
...and also shrink the explanation for alternate sharing approaches, a bit.

Actually, it looks like I already half-adopted it by accident. 😬 But this
commit adds it to the sidebar under "State", so users can browse to it. I'm
leaving the URL alone, because it's not urgent and we'll need to adjust a large
swath of URLs at some point anyway.

This change effectively stops presenting `terraform` as a provider in the normal
sense, and reduces /docs/providers/terraform/index.html to a ghost page in the
language section (to avoid breaking links for the time being). The message a
reader should get is that Terraform has one special built-in data source where
you don't need to think about the provider or its version.
2021-01-04 12:08:09 -08:00
Nick Fagerlund cc6a226bcf website: Remove provider category indexes, reduce main list
As of December 18, 2020, we've redirected nearly all of the provider
documentation that used to live on terraform.io:

- For providers that got published on the Registry, we redirected each docs page
to the corresponding Registry docs page.

- For providers that never got adopted by a new publisher, we archived the
GitHub repository and redirected each docs page to the corresponding Markdown
source file on github.com. (For an example of these redirects, see
https://www.terraform.io/docs/providers/telefonicaopencloud/r/s3_bucket.html)

There are ten providers left that we haven't redirected. These ones got adopted
by new publishers and _will_ end up on the Registry, but they aren't quite ready
to ship and get their permanent redirects, and we don't want to sabotage their
SEO by 301ing to a temporary destination.
2020-12-18 13:13:45 -08: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 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
Kristin Laemmert 79fd81775e
website/intro: remove outdated examples section (#26932) 2020-11-16 14:05:17 -05: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
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 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
Nick Fagerlund f9b8f6f21f website: Add wandering Plugin Signing page to publishing sidebar
This page file was already marked as belonging to the registry publishing docs,
but was unreachable because it wasn't included in the nav.
2020-10-26 18:21:29 -07:00
Nick Fagerlund 4cc9585fee website: Rename registry docs to "Publishing Providers & Modules"
Also, remove redundant sidebar_current noise from sidebar nav source.
2020-10-26 18:21:29 -07:00
Nick Fagerlund b98525ecc0 website: Decommission derelict "guides" section, move some content to "intro"
Guides was already mostly gone. The two major remaining bits (the "core
workflow" guide and the "recommended practices" guide, which deserves a rename)
make much more sense as highly technical marketing material, and thus have a
natural home in the intro section.
2020-10-26 18:21:29 -07:00
Martin Atkins ddf9635af6 website: Don't claim that things are "very easy"
We typically try to avoid making subjective, boasty claims in our
documentation in recent times, but there remained both some older
documentation that we've not recently revised and also some newer examples
that are, in retrospect, also perhaps more "boasty" than they need to be.

We prefer not to use this sort of boasty language because not everyone
using Terraform has the same background and experience, and so what is
"easy" or "intuitive" to one person may not be so to another person, and
that should not suggest that the second person is in any way wrong or
inadequate.

In reviewing some of our use of the word "easy" here I tried as much as
possible to surgically revise the existing content without getting drawn
into a big rewrite, but in some cases the content was either pretty
unsalvageable (due to talking about obsolete features that were removed
long ago) or required some broader changes to make the result hopefully
still get the same facts across. In those cases I've both removed some
content entirely or adjusted larger paragraphs.

This was not an exhaustive review and so I'm sure there's still plenty of
room for similar improvements elsewhere. I also resisted the urge to
update some pages that contain outdated information about currently-active
features.
2020-10-26 10:02:38 -07:00
Arthur Burkart d4716a69e1
lang/funcs: "anytrue" function
This is an analog to the "alltrue" function, using OR as the reduce
operator rather than AND.

This also includes some simplification of the "alltrue" implementation
to implement it similarly as a sort of reduce operation with AND
as the reduce operator, but with the same effective behavior.
2020-10-23 13:52:48 -07:00
Martin Atkins 1dc4950bfa lang/funcs: Rename the base64 character encoding functions
These were initially introduced as functions with "encode" and "decode"
prefixes, but that doesn't match with our existing convention of putting
the encoding format first so that the encode and decode functions will
group together in a alphabetically-ordered function list.

"text" is not really a defined serialization format, but it's a short word
that hopefully represents well enough what these functions are aiming to
encode and decode, while being consistent with existing functions like
jsonencode/jsondecode, yamlencode/yamldecode, etc.

The "base64" at the end here is less convincing because there is precedent
for that modifier to appear both at the beginning and the end in our
existing function names. I chose to put it at the end here because that
seems to be our emergent convention for situations where the base64
encoding is a sort of secondary modifier alongside the primary purpose
of the function, as we see with "filebase64". (base64gzip is an exception
here, but it seems outvoted by the others.)
2020-10-21 10:56:56 -07:00
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.
2020-10-12 15:29:42 -07:00
Martin Atkins 897cb72b36 website: Initial docs for the new dependency lock file behaviors
This includes both the main documentation about the lock file itself and
changes to related documentation about Terraform commands that interact
with the lock file.

We will likely continue to update this first pass of documentation as we
get feedback and questions during the prerelease period.
2020-10-09 09:26:23 -07:00
Nick Fagerlund 26f786959b
website: Update all Learn crosslinks (#26442)
* website: Update all Learn crosslinks

The URL structure on Learn recently changed, so it's time to update some URLs.

Co-authored-by: Tu Nguyen <im2nguyen@users.noreply.github.com>
2020-10-02 11:02:59 -07:00
Arthur Burkart 6ed47c7241
lang/funcs: Add "alltrue" function (#25656)
This commit adds an `alltrue` function to Terraform configuration. A
reason we might want this function is because it will enable more
powerful custom variable validations. For example:

```hcl
variable "amis" {
  type = list(object({
    id = string
  }))

  validation {
    condition = (alltrue([
      for a in var.amis : length(a.id) > 4 && substr(a.id, 0, 4) == "ami-"
    ]))
    error_message = "The ID of at least one AMI was invalid."
  }
}
```
2020-09-22 09:06:42 -04:00
Pam Selle 7032e651a8
Merge pull request #25927 from hashicorp/aug20_mirror_sidebar
website: fix nav link text for 'providers mirror'
2020-08-28 12:48:58 -04:00
Martin Atkins 2bd2a9a923 internal/getproviders: HTTPMirrorSource implementation
We previously had this just stubbed out because it was a stretch goal for
the v0.13.0 release and it ultimately didn't make it in.

Here we fill out the existing stub -- with a minor change to its interface
so it can access credentials -- with a client implementation that is
compatible with the directory structure produced by the
"terraform providers mirror" subcommand, were the result to be published
on a static file server.
2020-08-26 13:18:08 -07:00
Nick Fagerlund ff9218c105 website: fix nav link text for 'providers mirror' 2020-08-19 12:14:24 -07:00
Kristin Laemmert 470298006f website: add providers mirror command to providers sidebar 2020-08-14 10:03:31 -04:00
Pam Selle f63b261fca
Merge pull request #25791 from hashicorp/aug20_provisioners_nav
website: Move provisioners into language section of nav sidebar
2020-08-12 10:54:13 -04:00
Petros Kolyvas 50b2f0f9b2
Fix sidebar link for Terraform standard backends to include link to Kubernetes backend docs (#25792)
* website/layouts/backend-types.erb

* Update backend-types.erb
2020-08-10 20:25:14 -03:00
Nick Fagerlund 30b983e1e8 website: Move provisioners into language section of nav sidebar 2020-08-10 14:18:31 -07:00
Nick Fagerlund 7bc75a1804 website: Edits to updated Registry documentation
- Edits to registry overview
- Add index link as 'overview' (header links are semi-invisible)
- move providers/overview.html to providers/index.html
- Edits to providers overview
- fix filename of os-arch
- edits to provider publishing
2020-08-07 22:40:04 -07:00
Tony Carmichael cde98a3172 website: Update Registry documentation for Terraform 0.13 release
Co-authored-by: Tom Bamford <tbamford@hashicorp.com>
2020-08-07 22:40:04 -07:00
Nick Fagerlund 0e5651560b
Website: 0.13 docs edits, mostly around provider requirements (#25686)
* Make sidebar nav in language docs more intuitive
* Minor display fixes for registry docs
* Explain providers in the registry in the providers index
* Revise a bunch of language docs around provider reqs

This is mostly an effort to smooth out some of the explanations, make sure
things are presented in a helpful order, make sure terminology lines up, draw
connections between related concepts, make default behavior more apparent, and
the like. It shouldn't include very much new information, but there might be one
or two things that came out of a conversation somewhere.

Co-authored-by: Judith Malnick <judith@hashicorp.com>
2020-07-30 21:07:36 -07:00
Paul Tyng 19265fe4b0 Add recommend os/arch page 2020-07-21 10:05:40 -04:00
Sune Keller 4438df6131
website: Add cidrsubnets to IP Network Functions index (#25185)
Signed-off-by: Sune Keller <absukl@almbrand.dk>
2020-07-08 08:43:14 -04:00
Justin Campbell e85376990d
website: Terraform Registry Provider Publishing docs (#25378)
* website: Terraform Registry Provider Publishing

* website: (Registry) remove OS/arch recommendation

Until we have a canonical list to point to

Co-authored-by: Paul Tyng <ptyng@hashicorp.com>

Co-authored-by: Paul Tyng <ptyng@hashicorp.com>
2020-06-29 11:04:52 -04:00
Martin Atkins 02b130cd59 website: Terraform v0.13 upgrade guide 2020-06-25 09:24:41 -07:00
Martin Atkins f1ea705dbe website: Restore the docs for "terraform 0.12upgrade"
Although this command is removed in Terraform 0.13, our documentation is
for all versions of Terraform that remain in common use and keeping this
documented will be helpful for folks who are still using Terraform 0.11
and planning their upgrades to Terraform 0.12.

Both of the upgrade commands now include notes that they are only
available in their specific major version, along with a link to the
relevant upgrade guide for other background information about the upgrade,
in case the user finds the command documentation first. (The command docs
are, I think, a little more discoverable than the upgrade guides.)
2020-06-24 14:21:09 -07:00
Martin Atkins dc8fd14c1e website: "Provider Requirements" documentation
We previously covered everything about using providers on a single page,
but that was getting unwieldy already and we now have a lot more to
discuss with v0.13 introducing a new source address syntax and some other
concepts.

Here we split the provider-related content into two parts: "Provider
Requirements" covers how to find and declare dependencies on providers,
and then "Provider Configuration" (formerly just "Providers") then focuses
primarily on how to write zero or more provider configurations for a
particular provider.

Because "Provider Requirements" is now presented before "Provider
Configuration" in the navigation, I've also moved some of the introductory
content about providers in general onto the "Requirements" page. The
first paragraph of that content is duplicated onto the "Configuration"
page for discoverability, but we now link to the requirements page to get
the full story.
2020-06-18 09:31:52 -07:00