Commit Graph

23935 Commits

Author SHA1 Message Date
Ryan 1a53575b15 build: use correct link for GCP provider in GitHub issue template 2019-04-18 14:06:24 -07:00
Martin Atkins 168592825e release: clean up after v0.12.0-beta2 2019-04-18 17:30:16 +00:00
Chris Griggs aeabdf1a0d
Merge pull request #21054 from cgriggs01/cgriggs01-community-patch
[Website] Adding community provider
2019-04-18 09:19:39 -07:00
Pam Selle 3f68b12e3a
Merge pull request #20959 from mars/patch-1
Update CHANGELOG for #20561
2019-04-18 09:18:36 -07:00
Mars Hall 67b9a11fad Update CHANGELOG for #20561 2019-04-18 11:05:59 -05:00
Martin Atkins 533cbf4c3f
website: Update "Local Values" docs to use v0.12 syntax in example
There was some leftover v0.11-style interpolation syntax here.

We prefer to use a "naked" expression in situations like this where the result
isn't a string, because interpolations returning non-strings is a common source
of confusion for new users.
2019-04-18 09:03:34 -07:00
Chris Griggs f66b563ccd
Merge pull request #21051 from cgriggs01/cgriggs01-fortios-links
[Website] Adding Fortios provider links
2019-04-18 08:37:21 -07:00
cgriggs01 55b816853a [Website] Adding Fortios provider links 2019-04-18 07:46:30 -07:00
Martin Atkins 62d32e9bb3 website: Fix incorrect example in Module Composition page
The example above treats recordsets as a list, but the declaration was for a single object.
2019-04-18 07:13:16 -07:00
cgriggs01 26d515e40a Adding community provider 2019-04-17 15:57:24 -07:00
Alex Somesan 275e0a53f2
Merge pull request #20851 from hashicorp/doc-validatefunc-maps
Document that ValidateFunc works on maps.
2019-04-17 20:45:15 +02:00
Paul Tyng 6bd7fdbb6b
Merge pull request #21043 from hashicorp/paultyng-patch-1
godoc typo
2019-04-17 14:37:01 -04:00
Martin Atkins 2238fbda1b website: v0.12 upgrade guide about list variables and brackets 2019-04-17 11:16:16 -07:00
Alex Somesan 01a169c66f make fmt 2019-04-17 19:58:06 +02:00
Kristin Laemmert 83dea200c0
Update CHANGELOG.md 2019-04-17 13:50:02 -04:00
Przemysław Dąbek 9605b093d9 command/graph: use user-supplied plugin path when running graph command (#18083) 2019-04-17 13:48:11 -04:00
Paul Tyng ab2d09b0cb
godoc typo 2019-04-17 13:45:58 -04:00
Martin Atkins cbc8d1eba2 core: Input variables are always unknown during validate
Earlier on in the v0.12 development cycle we made the decision that the
validation walk should consider input values to always be unknown so that
validation is checking validity for all possible inputs rather than for
a specific set of inputs; checking for a specific set of inputs is the
responsibility of the plan walk.

However, we didn't implement that in the best way: we made the
"terraform validate" command force all of the input variables to unknown
but that was insufficient because it didn't also affect the implicit
validation walk we do as part of "terraform plan" and "terraform apply",
causing those to produce confusingly-different results.

Instead, we'll address the problem directly in the reference resolver code,
ensuring that all variable values will always be treated as an unknown
(of the declared type, so type checking is still possible) during any
validate walk, regardless of which command is running it.
2019-04-17 10:09:46 -07:00
Martin Atkins d7f23f0beb configs/configupgrade: Don't panic if analyzer fails
Previously we were trying to access a field of the analysis object before
checking if analysis produced errors. The analysis function usually
returns a nil analysis on error, so this would result in a panic whenever
that happened.

Now we'll dereference the analysis object pointer only after checking for
errors, so we'll get a chance to report the analysis error to the user.
2019-04-17 10:08:54 -07:00
Alex Somesan 0395c3ac58
Re-phrase docs to enumerate types which support ValidateFunc 2019-04-17 18:58:58 +02:00
Martin Atkins 1bb47ab9a5 configs/configupgrade: Preserve comments on items in object exprs
The expression upgrade functionality mostly ignores comments because in
the old language the syntax prevented comments from appearing in the
middle of expressions, but there was one exception: object expressions.

Because HCL 1 used ObjectType both for blocks and for object expressions,
that is the one situation where something we consider to be an expression
could have inline attached comments in the old language.

We migrate these here so we don't lose these comments that don't appear
anywhere else. Other comments get gathered up into a general comments
set maintained inside the analysis object and so will be printed out as
required _between_ expressions, just as they did before.
2019-04-17 07:48:57 -07:00
Martin Atkins 861a2ebf26 helper/schema: Use a more targeted shim for nested set diff applying
We previously attempted to make the special diff apply behavior for nested
sets of objects work with attribute mode by totally discarding attribute
mode for all shims.

In practice, that is too broad a solution: there are lots of other shimming
behaviors that we _don't_ want when attribute mode is enabled. In
particular, we need to make sure that the difference between null and
empty can be seen in configuration.

As a compromise then, we will give all of the shims access to the real
ConfigMode and then do a more specialized fixup within the diff-apply
logic: we'll construct a synthetic nested block schema and then use that
to run our existing logic to deal with nested sets of objects, while
using the previous behavior in all other cases.

In effect, this means that the special new behavior only applies when the
provider uses the opt-in ConfigMode setting on a particular attribute,
and thus this change has much less risk of causing broad, unintended
regressions elsewhere.
2019-04-17 07:47:31 -07:00
Martin Atkins 5f29339121
Update CHANGELOG.md 2019-04-17 07:41:27 -07:00
Martin Atkins ff2de9c818 core: Keep old value on error even for delete
When an operation fails, providers may return a null new value rather than
returning a partial state. In that case, we'd prefer to keep the old value
so that we stand the best chance of being able to retry on a subsequent
run.

Previously we were making an exception for the delete action, allowing
the result of that to be null even when an error is returned. In practice
that was a bad idea because it would cause Terraform to lose track of the
object even though it might not actually have been deleted.

Now we'll retain the old object even in the delete case. Providers can
still return partial new objects if they were able to partially complete
a delete operation, in which case we'll discard what we had before, but
if the result is null with errors then we'll assume the delete failed
entirely and so just keep the old state as-is, giving us the opportunity
to refresh it on the next run to see if anything actually happened after
all.

(This also includes a new resource in the test provider which isn't used
by the patch but was useful for some manual UX testing here, so I thought
I'd include it in case it's similarly useful in future, given how simple
its implementation is.)
2019-04-17 07:40:15 -07:00
Martin Atkins bd1a215580 helper/resource: Ignore Removed attributes for ImportStateVerify
Due to the lossiness of our legacy models for diff and state, shimming a
diff and then creating a state from it produces a different result than
shimming a state directly. That means that ImportStateVerify no longer
works as expected if there are any Computed attributes in the schema where
d.Set isn't called during Read.

Fixing that for every case would require some risky changes to the shim
behavior, so we're instead going to ask provider developers to address it
by adding `d.Set` calls where needed, since that is the contract for
"Computed" anyway -- a default value should be produced during Create, and
thus by extension during Import.

However, since a common situation where this occurs is attributes marked
as "Removed", since all of the code that deals with them has generally
been deleted, we'll avoid problems in that case here by treating Removed
attributes as ignored for the purposes of ImportStateVerify.

This required exporting some functionality that was formerly unexported
in helper/schema, but it's a relatively harmless schema introspection
function so shouldn't be a big deal to export it.
2019-04-16 11:14:49 -07:00
Martin Atkins c94f8f9067 website: Document division behavior change in v0.12 upgrade guide
The division operator now always performs floating point division, whereas
before it would choose between float and int division based on the types
of its arguments.

We have a specific error message for when a fractional number is used as
an index in HCL, but this additional upgrade guidance provides a specific
solution to the problem: the floor function.

Sadly we don't have enough context in the current design of the upgrade
tool to make this fix automatic. With some refactoring it may be possible
to apply the fix automatically within list brackets, but since that is
a relatively complex change we'll first try this manual solution prompted
by an error message, because in practice so far we've seen this reported
only in the context of list indexing and our error check will catch that
and make the user aware of the need for a fix there.
2019-04-16 10:03:37 -07:00
Martin Atkins 6a156f67ce vendor: go get github.com/hashicorp/hcl2@master
This includes a new specialized error message for when a fractional number
is used to index a sequence.
2019-04-16 10:03:37 -07:00
Martin Atkins bb118c37a2 configs: Handle "dynamic" blocks as special during override merging
Previously we were treating "dynamic" blocks in configuration the same as
any other block type when merging config bodies, so that dynamic blocks
in the override would override any dynamic blocks present in the base,
without considering the dynamic block type.

It's more useful and intuitive for us to treat dynamic blocks as if they
are instances of their given block type for the purpose of overriding.
That means a foo block can be overridden by a dynamic "foo" block and
vice-versa, and dynamic blocks of different types do not interact at all
during overriding.

This requires us to recognize dynamic blocks and treat them specially
during decoding of a merged body. We leave them unexpanded here because
this package is not responsible for dynamic block expansion (that happens
in the sibling "lang" package) but we do decode them enough to recognize
their labels so we can treat them as if they were blocks of the labelled
type.
2019-04-16 06:58:45 -07:00
Nick Fagerlund 5b90f66166
Merge pull request #21016 from hashicorp/apr19_null_resource
website: null_resource isn't a type of provisioner
2019-04-15 15:43:05 -07:00
Nick Fagerlund b4042947d1 website: null_resource isn't a type of provisioner
This page is useful, but it's easier to tell what it's for if we
put it next to the page about connections.
2019-04-15 14:11:02 -07:00
Kristin Laemmert dfcd2fb00c
Update CHANGELOG.md 2019-04-15 12:23:28 -04:00
Kristin Laemmert c1079b59bd
command/state_list.go: fix bug loading user-defined state (#21015)
* command/state_list.go: fix bug loading user-defined state

If the user supplied a state path via the `-state` flag and terraform
was running in a workspace other than `default`, the state was not being
loaded properly. Fixes #19920
2019-04-15 12:22:07 -04:00
Kristin Laemmert 8645b9703c
Update CHANGELOG.md 2019-04-12 14:10:16 -04:00
Kristin Laemmert d4669246c7
funcs/coalesce: return the first non-null, non-empty-string element from a sequence (#21002)
* funcs/coalesce: return the first non-null, non-empty element from a
sequence.

The go-cty coalesce function, which was originally used here, returns the
first non-null element from a sequence. Terraform 0.11's coalesce,
however, returns the first non-empty string from a list of strings.

This new coalesce function aims to preserve terraform's documented
functionality while adding support for additional argument types. The
tests include those in go-cty and adapted tests from the 0.11 version of
coalesce.

* website/docs: update coalesce function document
2019-04-12 13:57:52 -04:00
Chris Griggs e35e3d367e
Merge pull request #21001 from cgriggs01/cgriggs01-community-prvdrs
[Website] new community providers
2019-04-12 09:21:21 -07:00
Kristin Laemmert 1c95b21c6c
command/output: get the state path from the workspace or CLI argument (#20994)
Previously this command was setting the state path to the default state
file, instead of honoring the backend configuration.
2019-04-12 07:37:27 -04:00
Nick Fagerlund 88982fdbc3
website: in functions sidebar, default lists to collapsed (#20945)
Find-in-page is still supported with the 'expand/collapse all' control.
2019-04-11 16:54:18 -07:00
Sander van Harmelen f4607435aa
Merge pull request #20989 from hashicorp/svh/b-panic
Prevent a panic caused by writing to a nil map
2019-04-11 15:16:47 +02:00
Sander van Harmelen 90bc237b7b Prevent a panic caused by writing to a nil map 2019-04-11 14:34:14 +02:00
Martin Atkins 88e76fa9ef configs/configschema: Introduce the NestingGroup mode for blocks
In study of existing providers we've found a pattern we werent previously
accounting for of using a nested block type to represent a group of
arguments that relate to a particular feature that is always enabled but
where it improves configuration readability to group all of its settings
together in a nested block.

The existing NestingSingle was not a good fit for this because it is
designed under the assumption that the presence or absence of the block
has some significance in enabling or disabling the relevant feature, and
so for these always-active cases we'd generate a misleading plan where
the settings for the feature appear totally absent, rather than showing
the default values that will be selected.

NestingGroup is, therefore, a slight variation of NestingSingle where
presence vs. absence of the block is not distinguishable (it's never null)
and instead its contents are treated as unset when the block is absent.
This then in turn causes any default values associated with the nested
arguments to be honored and displayed in the plan whenever the block is
not explicitly configured.

The current SDK cannot activate this mode, but that's okay because its
"legacy type system" opt-out flag allows it to force a block to be
processed in this way anyway. We're adding this now so that we can
introduce the feature in a future SDK without causing a breaking change
to the protocol, since the set of possible block nesting modes is not
extensible.
2019-04-10 14:53:52 -07:00
Martin Atkins a20084dc0e configs/configschema: EmptyValue methods
These helpers determine the value that would be used for a particular
schema construct if the configuration construct it represents is not
present (or, in the case of *Block, empty) in the configuration.

This is different than cty.NullVal on the implied type because it might
return non-null "empty" values for certain constructs if their absence
would be reported as such during a decode with no required attributes or
blocks.
2019-04-10 14:53:52 -07:00
Michael Conlon 44c9e81d4c website: fix typo on the "terraform console" command page 2019-04-10 12:17:28 -07:00
cgriggs01 a674d3fb7b [Website] new community providers 2019-04-10 11:00:15 -07:00
Robert J b4e8e63618 Create smaller docker images for releases
Now we'll use build containers to perform preparation steps, causing the release
images to contain only Terraform itself and git/openssh.
2019-04-10 10:06:04 -07:00
James Bardin 5066003284
Merge pull request #20977 from hashicorp/jbardin/set-elem-get-ok
Don't allow unknown values in the config when generating the apply Diff
2019-04-10 11:16:48 -04:00
James Bardin 8d32229f7d add test fetching computed set value by address
This is not a recommended method, but it does serve to verify that the
set values in the ResourceData internal state are correctly computed,
which indicates that the expected configuration was passed in.
2019-04-10 09:42:54 -04:00
James Bardin af8115dc9b removing the ~ set flag is no longer needed
The computed set sigil ~ should no longer appear in the diffs, because
the config will be cleaned before generating the diff.
2019-04-10 09:39:45 -04:00
James Bardin 5f52aba3ae Remove unknown value strings from apply diffs
The synthetic config value used to create the Apply diff should contain
no unknown config values. Any remaining UnknownConfigValues were due to
that being used as a placeholder for values yet to be computed, and
these should be marked NewComputed in the diff.
2019-04-10 09:34:39 -04:00
James Bardin 7df3275120
Merge pull request #20957 from hashicorp/jbardin/shim-schemas
New methods for obtaining CoreConfigSchema for shimming
2019-04-08 18:16:40 -04:00
James Bardin 3ec93710fc PromoteSingle is used in 0.11 mode 2019-04-08 17:12:39 -04:00