Since we don't currently auto-install provisioner plugins this is
currently placed on the providers documentation page and referred to as
the "Provider Plugin Cache". In future this mechanism may also apply to
provisioners, in which case we'll figure out at that point where better
to place this information so it can be referenced from both the provider
and provisioner documentation pages.
This mechanism for configuring plugins is now deprecated, since it's not
capable of declaring plugin versions. Instead, we recommend just placing
plugins into a particular directory, which is now documented on the
main providers documentation page and linked from the more detailed docs
on plugins in general.
Previously we described inline here where to put the .terraformrc file,
but now we have a separate page all about this file that gives us more
room to describe in more detail where the file is placed and what else it
can do.
This function takes a map of lists of strings and inverts it so that
the string values become keys and the keys become items within the
corresponding lists.
In #15884 we adjusted the plan output to give an explicit command to run
to apply a plan, whereas before this command was just alluded to in the
prose.
Since releasing that, we've got good feedback that it's confusing to
include such instructions when Terraform is running in a workflow
automation tool, because such tools usually abstract away exactly what
commands are run and require users to take different actions to
proceed through the workflow.
To accommodate such environments while retaining helpful messages for
normal CLI usage, here we introduce a new environment variable
TF_IN_AUTOMATION which, when set to a non-empty value, is a hint to
Terraform that it isn't being run in an interactive command shell and
it should thus tone down the "next steps" messaging.
The documentation for this setting is included as part of the "...in
automation" guide since it's not generally useful in other cases. We also
intentionally disclaim comprehensive support for this since we want to
avoid creating an extreme number of "if running in automation..."
codepaths that would increase the testing matrix and hurt maintainability.
The focus is specifically on the output of the three commands we give in
the automation guide, which at present means the following two situations:
* "terraform init" does not include the final paragraphs that suggest
running "terraform plan" and tell you in what situations you might need
to re-run "terraform init".
* "terraform plan" does not include the final paragraphs that either
warn about not specifying "-out=..." or instruct to run
"terraform apply" with the generated plan file.
Previously we just assumed the reader was familiar with the idea of a
graph but didn't explain it.
Since graphs are an implementation detail of Terraform, rather than
essential information needed for new users, this revises the introduction
text to talk only about _dependencies_, which we assume the user is
familiar with as a more practical concept.
Additionally, Paul Hinze did a great talk on how Terraform uses graphs
at HashiConf 2016 which is good additional content for our existing
"Graph Internals" page, which includes a concise explanation of the
basics of graph theory.
In #15870 we got good feedback that it'd be more useful to have the
various filename-accepting arguments on this provisioner instead accept
strings that represent the contents of such files, so that they can be
generated from elsewhere in the Terraform config.
This change does not achieve that, but it does make room for doing this
later by renaming "minion_config" to "minion_config_file" so that we
can later add a "minion_config" option alongside that takes the file
content, and deprecate "minion_config_file".
Ideally we'd just implement the requested change immediately, but
unfortunately the release schedule doesn't have time for this so this is
a pragmatic change to allow us to make the full requested change at a
later date without backward incompatibilities.
This change is safe because the salt-masterless provisioner has not yet
been included in a release at the time of this commit.
Previously the -upgrade option was covered only on the "terraform init" usage page. It seems also worth mentioning in the main docs on provider versioning, since we're already explaining here other mechanics of the versioning/constraints system.
Terraform modules encapsulate their resources, and dependencies can only
be expressed through outputs, which wasn't clear to me in the existing
documentation. I'm hoping a small change will make that more explicit.
This escapes all characters that might have a special interpretation when embedded into a portion of a URL, including slashes, equals signs and ampersands.
Since Terraform's internals are not 8-bit clean (it assumes UTF-8
strings), we can't implement raw gzip directly. We're going to add
support where it makes sense for passing data to attributes as
base64 so that the result of this function can be used.
* update plugin/provider to make clear this section isn't needed for regular use
* add some links and notes about getting started
* remove the mention of binaries... I 'm not sure it's needed yet
* 'Installing Terraform Providers' section
* sometimes I can't words good
* move the 'installing providers' block
* cleanup of terms
* copy that update to plugins/provider too
The backend has been renamed. Using the old name in the config will
trigger a deprecation warning, but the implementation and the
documentation is the same.
Added locking support via blob leasing (requires that an empty state is
created before any lock can be acquired.
Added support for "environments" in much the same way as the S3 backend.
Fix the -state and -state-out wording to be consistent with other
commands. Remove the erroneous reference to remote state in the website
version of the flag description.
The docs did not mention that it is possible to provide overrides for specific
plugins by placing them into a `terraform.d/plugins/os_arch/` directory inside
the working dir.
Closes#15727.
This restores the earlier behavior of the first positional argument to
terraform init in 0.9, but as a command line option.
The positional argument was removed to improve consistency with other
commands that take a working directory as their first positional argument.
It was originally intended that this functionality would return in a
later release along with some other general improvements to Terraform's
module handling, but we're introducing here an interim solution that
uses the existing module source concept, to allow for easier porting of
workflows that previously depended on the automatic copy behavior.
In a future release this feature may change again as the module
improvements design firms up, but we expect it to be broadly compatible
with this temporary state.
The "terraform init" command has a lot of different functionality now,
making it hard to follow all of the options in the previous presentation.
Instead, here we describe each of the steps and its associated options
separately, hopefully making it easier to understand what each option
relates to.
In addition, much of the detail around backend partial configuration is
factored out into the backend configuration page, where it seems more
"at home"; previously it felt hard to follow exactly how partial
configuration would be used, due to the information on it being split over
two different pages.
This is documented for all other Hashicorp products using this service but
was missed for Terraform. This serves as a disclosure of the fact that
Terraform reaches out to a Hashicorp service, an explanation of the
purpose of that request, and instructions on how to disable it in
environments where it is inappropriate or cannot be supported due to a
firewall or other connectivity restrictions.
Based on feedback from #15569 that the previous example was too abstract
and did not give enough context about what each of the different arguments
mean and how they generalize to other resource types.
The intent here is just to introduce some initial docs on our recommended
way to develop plugins in the same GOPATH as Terraform itself. The
documentation in this area needs some more fundamental rework as it is
rather outdated and mis-organized, but that's outside the scope of what
this change is trying to achieve.
This changed close to the release of beta1 to use underscores as the
separator and to use a lower-case "v" to avoid any issues on
case-insensitive filesystems.
A common reason to want to use `terraform plan` is to have a chance to
review and confirm a plan before running it. If in fact that is the
only reason you are running plan, this new `terraform apply -auto-approve=false`
flag provides an easier alternative to
P=$(mktemp -t plan)
terraform refresh
terraform plan -refresh=false -out=$P
terraform apply $P
rm $P
The flag defaults to true for now, but in a future version of Terraform it will
default to false.
Error loading Terraform: Error downloading modules: error downloading 'ssh://git@bitbucket.org/acme/foo.git?bar': /usr/bin/git exited with 128: Cloning into '.terraform/modules/yadayada'...
invalid command syntax.
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
This guide covers assorted best practices and caveats for running
Terraform within orchestration tools and other automation. It provides
general examples and guidance, with the intent that this advice can be
adapted by the reader to a concrete implementation within a selected
orchestration tool.
This guide is based both on our in-house experience with Terraform
Enterprise and on in-house solutions we are aware of in certain
organizations.
Previously the behavior for -target when given a module address was to
target only resources directly within that module, ignoring any resources
defined in child modules.
This behavior turned out to be counter-intuitive, since users expected
the -target address to be interpreted hierarchically.
We'll now use the new "Contains" function for addresses, which provides
a hierarchical "containment" concept that is more consistent with user
expectations. In particular, it allows module.foo to match
module.foo.module.bar.aws_instance.baz, where before that would not have
been true.
Since Contains isn't commutative (unlike Equals) this requires some
special handling for targeting specific indices. When given an argument
like -target=aws_instance.foo[0], the initial graph construction (for
both plan and refresh) is for the resource nodes from configuration, which
have not yet been expanded to separate indexed instances. Thus we need
to do the first pass of TargetsTransformer in mode where indices are
ignored, with the work then completed by the DynamicExpand method which
re-applies the TargetsTransformer in index-sensitive mode.
This is a breaking change for anyone depending on the previous behavior
of -target, since it will now select more resources than before. There is
no way provided to obtain the previous behavior. Eventually we may support
negative targeting, which could then combine with positive targets to
regain the previous behavior as an explicit choice.
We are replacing this terminology. The old command continues to work for
compatibility, but is deprecated. The docs should reflect the
currently-recommended form.
We are moving away from using the term "environment" to describe separate
named states for a single config, using "workspace" instead. The old
attribute name remains supported for backward compatibility, but is
marked as deprecated.
"environment" is a very overloaded term, so here we prefer to use the
term "working directory" to talk about a local directory where operations
are executed on a given Terraform configuration.
This form of "terraform init" is vestigial at this point and being phased
out in 0.10. Something similar may return in a later version for
installing modules from a more formal module library, but for now we are
advising to use git manually to simplify the UX for "terraform init".
Previously we encouraged users to import a resource and _then_ write the
configuration block for it. This ordering creates lots of risk, since
for various reasons users can end up subsequently running Terraform
without any configuration in place, which then causes Terraform to want
to destroy the resource that was imported.
Now we invert this and require a minimal configuration block be written
first. This helps ensure that the user ends up with a correlated resource
config and state, protecting against any inconsistency caused by typos.
This addresses #11835.
This will be fleshed out later as part of more holistic documentation for
the new provider plugin separation, but this is some minimal documentation
for just this subcommand.
* Data Source support for Resource Group
* Better message for mismatching locations.
* Reuse existing read code
* Adds documentation
* Adds test
* Adds a function for composing ID strings
* Change location to computed.
* Move to v2 client in vendor directory
* Move to v2 api and project IDs for environments
* add host label support to registration command
* Update go-rancher/catalog
* Allow go-rancher to handle URL versioning
This is a separate resource that serves a similar purpose to the
propagating_vgws argument on aws_route_table, but allows route
propagations to be created independently of the route table, which in
turn allows the VPN gateway to be created after the route table it will
contribute to, possibly in a separate Terraform module.
To make this work, propagating_vgws on aws_route_table is now marked
as Computed, meaning that it won't try to delete any existing propagation
edges if there is no setting for it in configuration at all. This allows
the user to choose whether to use the argument or the separate resource,
though using both together will not work, as explained in the docs.
* Update overview/API links for storage_bucket_objects, and acls for both buckets and objects.
* Minor formatting changes to google_storage_bucket and acl docs.
* Updated outdated custom ACL information and fixed grammar.
* Added support for public IP data source. Tested manually.
* WIP: Update to implementation, basic test added.
* WIP: Updates to implementation, basic test added.
* WIP: Added support for idle timeout
* Completed implementation and basic test
* Added documentation.
* Updated the example so it makes a little more sense.
* Add task_parameters support to aws_ssm_maintenance_window_task
task_parameters weren't supported yet. This adds support for them. It
also corrects a documentation typo in the maintenance_window resource.
* Respond to internal feedback
* New SSM Parameter resource
Can be used for creating parameters in AWS' SSM Parameter Store that can then be used by other applications that have access to AWS and necessary IAM permissions.
* Add docs for new SSM Parameter resource
* Code Review and Bug Hunt and KMS Key
- Addressed all issues in #14043
- Added ForceNew directive to type
- Added the ability to specify a KMS key for encryption and decryption
* Add SSM Parameter Data Source
* Fix bad merge
* Fix SSM Parameter Integration Tests
* docs/aws: Fix typo in SSM sidebar link
* Make os_profile optional #11147
* Test for optional os_profile and fix resourceArmVirtualMachineRead
* Updating to match other optionally-required fields
Datadog does not explicitly document which graph types are available, but when you use the GUI to generate the graph and select the JSON tab to inspect said graph, you will see that the available timeboard graph type names are singular, not plural.
* provider/aws: Update Lightsail supported regions
This commit complements (#14621)[https://github.com/hashicorp/terraform/pull/14621] and (#14685)[https://github.com/hashicorp/terraform/pull/14685].
* Revert "provider/aws: Update Lightsail supported regions"
This reverts commit 545c3d6e6e7a9b665542ecc3b5e4d857faac749b.
* This commit complements #14621 and #14685.
* Link to AWS docs instead of listing regions
Instead of explicitly listing supported Lightsail regions in the docs,
we now link to the Lightsail docs.
* Updating the Sku field to be optional
* Making the Sku optional
* Ensuring we check for a 404 to mark a successful deletion
* Upping the size of the internal data disk
* Randomizing the Local Network Gateway tests
* Fixing a bug in Local Network Gateway's where the deletion wouldn't be detected
This fixes the missing `id` attribute on the documentation. The attribute exists if called via `"${aws_elastic_beanstalk_environment.myapp-environment.id}"`, but is just not documented.
Should not be cherry-picked to the `stable-website` branch. The next Terraform deploy will include the latest changes to the OPC provider, and this updated documentation for the next point release.
* vendor: Add gophercloud/routerinsertion package and update
gophercloud/firewall to support router insertion
* provider/openstack: Add support for associating
`openstack_fw_firewall_v1` resources with router(s).
Added `associated_routers` and `no_routers` arguments.
* website: Add documentation for `associated_routers`and `no_routers` arguments on `openstack_fw_firewall_v1` resource.
* provider/openstack: Add `AddValueSpecs` function and refactor existing
uses.
* fix gitlab naming
seems like some github stuff was not renamed
* gitlab is using group or user instead of organisations
* add namespace_id to gitlab_project documentation
* it's not possible to manage group members
* Fix doc bug. Spell `collation` like `lc_collate`.
* Whitespace nit in error message
* Use %q as the format verb for error messages in postgresql_database resource messages.
* REVOKE the `GRANT` given to the connection user when creating a database.
For `ROLE`s who have been delegated `CREATEDB` privileges and are not a
superuser, in order for them to `CREATE DATABASE` they need to be a member
of the `ROLE` who will be `OWNER` for the new database. Once the
`CREATE DATABASE` is complete, `REVOKE` the `GRANT` that was given to role
so that the user who ran the `CREATE DATABASE` looses all privileges to the
target database (unless of course they're a superuser).
Fixes a regression introduced in #11452
* Delegated DBA ROLEs can now fix OWNER drift for PostgreSQL databases.
Uses the helper functions introduced in #11452
Aleksejs Sinicins