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
* provider/aws: Add data source for aws_elasticache_cluster
Fixes: #11445
* provider/aws: Add acceptance tests for aws_elasticache_cluster data source
* provider/aws: Add documentation for the aws_elasticache_cluster datasource
Add dynamodb_table and deprecation notice on lock_table. Add missing
parameters for the S3 backends: assume_role_policy, external_id,
and session_name.
* provider:openstack Add support provider network
* revert vendor file changes
* vendor: Updating Gophercloud for OpenStack Provider
* create provider network if parameter has segments
* segments is not computed resource
* extract to generate []provider.Segment
* change segmentstion id type
* provider/gitlab: Fix documentation copypasta
The original provider and docs were copied from the github provider, one
bit of copy paste slipped unmissed.
* provider/gitlab: Document `gitlab_project#id`
* provider/gitlab: Document `gitlab_project#namespace_id`
* provider/gitlab: Add fuller demonstration to the provider page
Following in the style of other provider pages, add a worked example
showing off all of the available resources offered by the gitlab
provider.
* provider/gitlab: Correct sample for gitlab_project
* The resource name should be consistent.
The HCL declares the terraform_remote_state with a resource name of foo. But the example invocation uses network which is incorrect.
* Foo > Network so this is a proper example.
A while back `atlas_artifact` was switched from being a `resource` to a `data` provider. When you use the examples suggested in the Terraform Enterprise docs, the Terraform cli shows a deprecation warning and provides an old url to the new data provider docs.
There are some complimentary doc updates in the Terraform Enterprise/Atlas repo.
* vendor: Updating Gophercloud for OpenStack Provider
* provider/openstack: Enable Security Group Updates
This commit enables security group names and descriptions to
be updated without causing a recreate.
* Update news section with April 4 webinar video
* Use YAML data file for news; add webinar registration CTA
* Update news section with Google Cloud webinar post-event info
* Exposing moid value from vm resource
moid value is needed by NSX resources, like security tag, when we attached security tags to a VMs, so needed before we commit NSX provider.
* fixing gofmt issue
* Updating docs regarding new exported moid attribute.
* vendor: Update go-gitlab to master@e6c11e
Update go-gitlab to master@e6c11e. This brings in UpdateGroup in
addition to fuller management of other attributes.
* provider/gitlab: Add `gitlab_group` resource
This adds a gitlab_group resource.
This combined with #14483 will allow you to create projects in a
group.
* Update sources.html.markdown
Moduels not updating was really annoying, should add this documentation in to increase usability of the feature.
* Update sources.html.markdown
* provider/gitlab: add `gitlab_deploy_key`
Here we extend the gitlab provider further by adding a `gitlab_deploy_key`
resource. This resource allows management of a projects deploy
keys.
* provider/gitlab: Do not test `gitlab_deploy_key` `can_push`
Here we remove the testing of the `can_push` attribute. This makes the
tests less comprehensive, but will allow them to work with the current
release of gitlab-ce.
This change is staged as a distinct commit so it can be easily
dropped/reverted once gitlab MR !11607 has reached a released state.
https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/11607
* provider/gitlab: Update docs for gitlab_deploy_key/can_push
Note that the can_push attribute of gitlab_deploy_key doesn't currently
work. This note can be removed once
https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/11607 is merged
and in general circulation.
system volumes on scaleway can't easily be modified - instead one has to create
a new image with the desired system volume size. This is way out of scope of
terraform - see https://community.online.net/t/expanding-lssd/907/2 for steps on
how to build a new image.
the `scaleway_server` `volume` attribute should only be used if you want to
attach additional volumes to a server which will share the lifetime of the
server, e.g. they will be destroyed once the server is shut down.
To have volumes which outlive the attached server one should use
`scaleway_volume` and `scaleway_volume_attachement` instead.
Prior to Terraform 0.7, lists in Terraform were just a shallow abstraction
on top of strings with a magic delimiter between items. Wrapping a single
string in brackets in the configuration was Terraform's prompt that it
needed to split the string on that delimiter during interpolation.
In 0.7, when first-class lists were added, this convention was preserved
by flattening lists-of-lists by one level when they were encountered in
configuration. However, there was an oversight in that change where it
did not correctly handle the case where the inner list was unknown.
In #14135 we removed some code that was flattening partially-unknown lists
into fully-unknown (untyped) values. This inadvertently exposed the missed
case from the previous paragraph, causing issues for list-wrapped splat
expressions with unknown members. While this worked fine for resources,
due to some fixup done inside helper/schema, this did not work for other
interpolation contexts such as module blocks.
Various attempts to fix this up and restore the flattening behavior
selectively were unsuccessful, due to a proliferation of assumptions all
over the core code that would be too risky to change just to fix this bug.
This change, then, takes the different approach of removing the
requirement that splats be presented inside list brackets. This
requirement didn't make much sense anymore anyway, since no other
list-returning expression had this constraint and so the rest of Terraform
was already successfully dealing with both cases.
This leaves us with two different scenarios:
- For resource arguments, existing normalization code in helper/schema
does its own flattening that preserves compatibility with the common
practice of using bracketed splats. This change proves this with a test
within the "test" provider that exercises the whole Terraform core and
helper/schema stack that assigns bracketed splats to list and set
attributes.
- For arguments in other blocks, such as in module callsites, the
interpolator's own flattening behavior applies to known lists,
preserving compatibility with configurations from before
partially-computed splats were possible, but those wishing to use
partially-computed splats are required to drop the surrounding brackets.
This is less concerning because this scenario was introduced only in
0.9.5, so the scope for breakage is limited to those who adopted this
new feature quickly after upgrading.
As of this commit, the recommendation is to stop using brackets around
splats but the old form continues to be supported for backward
compatibility. In a future _major_ version of Terraform we will probably
phase out this legacy form to improve consistency, but for now both
forms are acceptable at the expense of some (pre-existing) weird behavior
when _actual_ lists-of-lists are used.
This addresses #14521 by officially adopting the suggested workaround of
dropping the brackets around the splat. However, it doesn't yet allow
passing of a partially-unknown list between modules: that still violates
assumptions in Terraform's core, so for the moment partially-unknown lists
work only within a _single_ interpolation expression, and cannot be
passed around between expressions. Until more holistic work is done to
improve Terraform's type handling, passing a partially-unknown splat
through to a module will result in a fully-unknown list emerging on
the other side, just as was the case before #14135; this change just
addresses the fact that this was failing with an error in 0.9.5.
* Support importing google_sql_user
* Updated documentation to reflect that passwords are not retrieved.
* Added additional documentation detailing use.
* Removed unneeded d.setId() line from GoogleSqlUser Read method.
* Changed an errors.New() call to fmt.Errorf().
* Migrate schemas of existing GoogleSqlUser resources.
* Remove explicitly setting 'id' property
* Added google_sql_user to importability page.
* Changed separator to '/' from '.' and updated tests + debug messages.
Paul Banks