* website: plannable import docs
* website: config gen docs
* Update website/docs/cli/commands/plan.mdx
Co-authored-by: Rose M Koron <32436232+rkoron007@users.noreply.github.com>
* Update website/docs/cli/import/index.mdx
Co-authored-by: Rose M Koron <32436232+rkoron007@users.noreply.github.com>
* Update website/docs/language/import/index.mdx
Co-authored-by: Rose M Koron <32436232+rkoron007@users.noreply.github.com>
* Update website/docs/language/import/index.mdx
Co-authored-by: Rose M Koron <32436232+rkoron007@users.noreply.github.com>
* Apply suggestions from code review
Co-authored-by: Rose M Koron <32436232+rkoron007@users.noreply.github.com>
* fix docs rendering
* Apply suggestions from code review
Co-authored-by: Rose M Koron <32436232+rkoron007@users.noreply.github.com>
* link again to import blocks
* fix genconfig example plan output
* Update website/docs/language/import/index.mdx
Co-authored-by: Rose M Koron <32436232+rkoron007@users.noreply.github.com>
* add import resource config example
* Apply suggestions from code review
Co-authored-by: Rose M Koron <32436232+rkoron007@users.noreply.github.com>
* attempt to fix nav
* more explicit
* fix build?
* remove pseudo tutorial
* add advice on when to gen
* add note on idempotency
* Apply suggestions from code review
Co-authored-by: Rose M Koron <32436232+rkoron007@users.noreply.github.com>
Co-authored-by: Alan Szlosek Jr <alan.szlosek@hashicorp.com>
* refer to cli cmd in usual way
* more explanation for genconfig
* remove unnecessary sentence
* add heading
* update help text
* Apply suggestions from code review
Co-authored-by: Rose M Koron <32436232+rkoron007@users.noreply.github.com>
* update link
* add import ID section
* Apply suggestions from code review
Co-authored-by: rita <8647768+ritsok@users.noreply.github.com>
Co-authored-by: Rose M Koron <32436232+rkoron007@users.noreply.github.com>
* Apply suggestions from code review
Co-authored-by: rita <8647768+ritsok@users.noreply.github.com>
Co-authored-by: Rose M Koron <32436232+rkoron007@users.noreply.github.com>
* dial back didacticism
* clarify genconfig instructions
* explicit explanation of arg conflict
* Apply suggestions from code review
Co-authored-by: rita <8647768+ritsok@users.noreply.github.com>
Co-authored-by: Rose M Koron <32436232+rkoron007@users.noreply.github.com>
* clarify import block required for genconfig
---------
Co-authored-by: Rose M Koron <32436232+rkoron007@users.noreply.github.com>
Co-authored-by: Alan Szlosek Jr <alan.szlosek@hashicorp.com>
Co-authored-by: rita <8647768+ritsok@users.noreply.github.com>
* Add documentation page for checks and assertions
* address comments
* Apply suggestions from code review
Co-authored-by: Rose M Koron <32436232+rkoron007@users.noreply.github.com>
* address comments
* Apply suggestions from code review
Co-authored-by: Radek Simko <radek.simko@gmail.com>
Co-authored-by: Rose M Koron <32436232+rkoron007@users.noreply.github.com>
* address comments
* Apply suggestions from code review
Co-authored-by: Rose M Koron <32436232+rkoron007@users.noreply.github.com>
* revamp choosing checks or other custom conditions section
* expand on depends_on
* fix issues link
* Apply suggestions from code review
Co-authored-by: Rose M Koron <32436232+rkoron007@users.noreply.github.com>
* address comments
* Apply suggestions from code review
Co-authored-by: Rose M Koron <32436232+rkoron007@users.noreply.github.com>
---------
Co-authored-by: Rose M Koron <32436232+rkoron007@users.noreply.github.com>
Co-authored-by: Radek Simko <radek.simko@gmail.com>
There aren't any super significant upgrade considerations this time, so
this is really just a summary of the two main entries in the changelog.
There is also an entry in the changelog about ending support for older
versions of Windows, but in that case we are just passing on a release
note from Go itself and we already warned against using versions earlier
than Windows 10 back in Terraform v0.15 (since we are relying on the
Windows 10 console API) and so this is just one additional reason why
Terraform might not work correctly on those earlier versions of Windows,
so not worth mentioning in the upgrade guide here since our guidance
hasn't changed.
* cloud: assert import block compatibility
* check for import <> TFC compatibility during init
* imports are not in alphabetical order 🙃
---------
Co-authored-by: CJ Horton <cjhorton@hashicorp.com>
This temporary measure prevents a panic further down the line when there is an unmatched expanded resource instance import target when running in config gen mode.
This minor release includes a number of security fixes and other small bug
fixes in the standard library and Go compiler.
The security fixes do not appear to involve functionality critical to
Terraform and so this is not an urgent upgrade, but still worth doing to
reset to a more recent baseline.
HashiCorp legal now requires a copyright claim in a comment at the top of
every substantial file in this repository. If we don't add this ourselves
then a bot will open a PR to add missing entries, but that process adds
git history, pull request, and GitHub notification noise so instead we'll
deal with it proactively as part of our usual code generation steps.
This means that pull requests will fail their checks if there are any
files that lack copyright headers, so we can deal with those before we
merge rather than in a subsequent PR.
This introduces the "refinements" concept from upstream cty, which allows Terraform to track some additional information about unknown values that constrains their possible range even though we don't yet know the final value.
This is actually a description of the "cty" library's encoding of refined
values, but from the perspective of the plugin protocol it's an
implementation detail that Terraform Core outsources that to a third-party
library, and current server-side implementations of the protocol use an
independent implementation of this format which will need to be compatible
with what cty does.
Providers that existed prior to refinements (all of them, at the time of
writing) cannot preserve refinements sent in unknown values in the
configuration, and even if one day providers _are_ aware of refinements
there we might add new ones that existing providers don't know how to
handle.
For that reason we'll absolve providers of the responsibility of
preserving refinements from config into plan by fixing some cases where
we were incorrectly using RawEquals to compare values; that function isn't
appropriate for comparing values that might be unknown.
However, to avoid a disruptive change right now this initial fix just
strips off the refinements before comparing. Ideally this should be using
Value.Equals and handling unknown values more explicitly, but we'll save
that for a possible later improvement.
This does not include a similar exception for validating whether a final
value conforms to a plan because the plan value and the final value are
both produced by the same provider and so providers ought to be able to
be consistent with their _own_ treatment of refinements, if any.
Configuration is special because Terraform itself generates that, and so
it can potentially contain refinements that a particular provider has no
awareness of.
If the original value was unknown but its range was refined then the
provider must return a value that is within the refined range, because
otherwise downstream planning decisions could be invalidated.
This relies on cty's definition of whether a value is in a refined range,
which has pretty good coverage for the "false" case and so should give a
pretty good signal, but it'll probably improve over time and so providers
must not rely on any loopholes in the current implementation and must
keep their promises even if Terraform can't currently check them.
If the string to be tested is an unknown value that's been refined with
a prefix and the prefix we're being asked to test is in turn a prefix of
that known prefix then we can return a known answer despite the inputs
not being fully known.
There are also some other similar deductions we can make about other
combinations of inputs.
This extra analysis could be useful in a custom condition check that
requires a string with a particular prefix, since it can allow the
condition to fail even on partially-unknown input, thereby giving earlier
feedback about a problem.
The "id" attribute of this resource type is generated by the provider
itself and can never be null, so we'll refine the range of its unknown
result in case that helps downstream expressions to produce known results
even when the exact value hasn't yet been planned.
cty's new "refinements" concept allows us to reduce the range of unknown
values from our functions. This initial changeset focuses only on
declaring which functions are guaranteed to return a non-null result,
which is a helpful baseline refinement because it allows "== null" and
"!= null" tests to produce known results even when the given value is
otherwise unknown.
This commit also includes some updates to test results that are now
refined based on cty's own built-in refinement behaviors, just as a
result of us having updated cty in the previous commit.
* genconfig: fix nil nested block panic
* genconfig: null NestingSingle blocks should be absent
A NestingSingle block that is null in state should be completely absent from config.
* configschema: make FilterOr variadic
* configschema: apply filters to nested types
* configschema: filter helper/schema id attribute
The legacy SDK adds an Optional+Computed "id" attribute to the
resource schema even if not defined in provider code.
During validation, however, the presence of an extraneous "id"
attribute in config will cause an error.
Remove this attribute so we do not generate an "id" attribute
where there is a risk that it is not in the real resource schema.
* configschema: filter test
* terraform: do not pre-validate generated config
Config generated from a resource's import state may fail validation in
the case of schema behaviours such as ExactlyOneOf and ConflictsWith.
We don't want to fail the plan now, because that would give the user no
way to proceed and fix the config to make it valid. We allow the plan to
complete and output the generated config.
* generate config alongside import process
Rather than waiting until we call `plan()`, generate the configuration
at the point of the import call, so we have the necessary data to return
in case planning fails later.
The `plan` and `state` predeclared variables in the plan() method were
obfuscating the actual return of nil throughout, so those identifiers
were removed for clarity.
* move generateHCLStringAttributes closer to caller
* store generated config in plan on error
* test for config gen with error
* add simple warning when generating config
---------
Co-authored-by: James Bardin <j.bardin@gmail.com>
Previously we just made a hard rule that the state storage for Terraform
Cloud would never save any intermediate snapshots at all, as a coarse way
to mitigate concerns over heightened Terraform Enterprise storage caused
by saving intermediate snapshots.
As a better compromise, we'll now create intermediate snapshots at the
default interval unless the Terraform Cloud API responds with a special
extra header field X-Terraform-Snapshot-Interval, which specifies a
different number of seconds (up to 1 hour) to wait before saving the next
snapshot.
This will then allow Terraform Cloud and Enterprise to provide some dynamic
backpressure when needed, either to reduce the disk usage in Terraform
Enterprise or in situations where Terraform Cloud is under unusual load
and needs to calm the periodic intermediate snapshot writes from clients.
This respects the "force persist" mode so that if Terraform CLI is
interrupted with SIGINT then it'll still be able to urgently persist
a snapshot of whatever state it currently has, in anticipation of probably
being terminated with a more aggressive signal very soon.
We've seen some concern about the additional storage usage implied by
creating intermediate state snapshots for particularly long apply phases
that can arise when managing a large number of resource instances together
in a single workspace.
This is an initial coarse approach to solving that concern, just restoring
the original behavior when running inside Terraform Cloud or Enterprise
for now and not creating snapshots at all.
This is here as a solution of last resort in case we cannot find a better
compromise before the v1.5.0 final release. Hopefully a future commit
will implement a more subtle take on this which still gets some of the
benefits when running in a Terraform Enterprise environment but in a way
that will hopefully be less concerning for Terraform Enterprise
administrators.
This does not affect any other state storage implementation except the
Terraform Cloud integration and the "remote" backend's state storage when
running inside a TFC/TFE-driven remote execution environment.
Previously we just always used the same intermediate state persistence
behavior for all state storages. However, some storages might have access
to additional information that allows them to tailor when they persist,
such as reacting to API rate limit status headers in responses, or just
knowing that a particular storage isn't suited to intermediate snapshots
at all for some reason.
This commit doesn't actually change any observable behavior yet, but it
introduces an optional means for a state storage to customize the behavior
which we may make use of in certain storage implementations in future
commits.
