Commit Graph

20853 Commits

Author SHA1 Message Date
James Bardin 09180a10ff cannot destroy without a config 2017-11-07 21:23:37 -05:00
James Bardin d62e9217ae update test state strings for backend/local 2017-11-07 21:23:10 -05:00
James Bardin 3c807e5427 update state test strings in command package 2017-11-07 21:18:08 -05:00
James Bardin d613959cda write provider to state for import nodes
and update the test state strings
2017-11-07 21:05:37 -05:00
James Bardin 3977fe8b2d write provider to state for refresh nodes
and update the test state strings
2017-11-07 21:05:28 -05:00
James Bardin c2f3522f7d write providers to state for data resources
And update the test state strings

Destroying with no config is no longer allowed, run an exlpicit destroy
for the destroyOrder test.
2017-11-07 21:05:21 -05:00
James Bardin 8dfaae1f23 rewrite all of the test state string for providers
Now that the resolved provider is always stored in state, we need to
udpate all the test data to match. There will probably be some more
breakage once the provider field is properly diffed.
2017-11-07 13:49:43 -05:00
James Bardin b79adeae02 save resolved providers for resources to state
Use the ResourceState.Provider field to store the full name of the
provider used during apply. This field is only used when a resource is
removed from the config, and will allow that resource to be removed by
the exact same provider with which it was created.

Modify the locations which might accept the alue of the
ResourceState.Provider field to detect that the name is resolved.
2017-11-07 13:09:36 -05:00
James Bardin 990acca758 remove commented out fields 2017-11-07 10:15:11 -05:00
James Bardin b9b4912bfb complete passing providers through modules
Here we complete the passing of providers between modules via the
module/providers configuration, add another test and update broken test
outputs.

The DisbableProviderTransformer is being removed, since it was really
only for provider configuration inheritance. Since configuration is no
longer inherited, there's no need to keep around unused providers. The
actually shouldn't be any unused providers going into the graph any
longer, but put off verifying that condition for later.  Replace it's
usage with the PruneProviderTransformer, and use that to also remove the
unneeded proxy provider nodes.
2017-11-07 09:41:57 -05:00
James Bardin 49e6ecfd7a pass providers into modules via config
Implement the adding of provider through the module/providers map in the
configuration.

The way this works is that we start walking the module tree from the
top, and for any instance of a provider that can accept a configuration
through the parent's module/provider map, we add a proxy node that
provides the real name and a pointer to the actual parent provider node.
Multiple proxies can be chained back to the original provider.  When
connecting resources to providers, if that provider is a proxy, we can
then connect the resource directly to the proxied node. The proxies are
later removed by the DisabledProviderTransformer.

This should re-instate the 0.11 beta inheritance behavior, but will
allow us to later store the actual concrete provider used by a resource,
so that it can be re-connected if it's orphaned by removing its module
configuration.
2017-11-06 21:57:06 -05:00
James Bardin b15258dfec remove provider inheritance from Tree.Load
Now that resources can be connected to providers with different paths in
the core graph, handling the inheritance in config makes less sense.

Removing this to make room for core to walk the Tree and connect
resources directly to the proper provider instance.
2017-11-06 17:27:45 -05:00
James Bardin 57470f6bf5 remove ProviderConfig Path and Inherited fields
maving all inheritance into core
2017-11-06 17:11:07 -05:00
James Bardin 3297f60d03 remove raw print statements 2017-11-06 17:10:33 -05:00
James Bardin 6302916e65
Merge pull request #16572 from hashicorp/jbardin/provider-config
don't add missing provider aliases to the graph
2017-11-06 15:03:27 -05:00
James Bardin a089a4ba21
Merge pull request #16573 from hashicorp/jbardin/ProvidedBy
Minor cleanup, ProvidedBy return value is a single string
2017-11-06 15:03:12 -05:00
James Bardin 72d4e15c47 ProvidedBy return value is a single string
Clean up ProvidedBy, which doesn't need to be a slice.
2017-11-06 14:27:01 -05:00
James Bardin d9d21d4200 don't add missing provider aliases to the graph
A missing provider alias should not be implicitly added to the graph.

Run the AttachaProviderConfigTransformer immediately after adding the
providers, since the ProviderConfigTransformer should have just added
these nodes.
2017-11-06 14:21:28 -05:00
Malik Bougacha ed0d57d1b7 Get the enviroment from the environment variable (#16326)
* Get the enviroment from the enviroment variable

* typo
2017-11-06 16:59:48 +00:00
James Belchamber ec2281106f Adding documentation for all supported imports in the Heroku provider (#16312) 2017-11-06 16:57:57 +00:00
Dominik Lekse 323654a716 Fixed documentation of azurerm backend advanced access variables (#16552)
Signed-off-by: Dominik Lekse <dominik@lekse.de>
2017-11-06 16:54:30 +00:00
Chris Marchesi 1bed7deb8f
Merge pull request #16565 from hashicorp/b-mapwriter-overwrites
helper/schema: Clear existing map/set/list contents before overwriting
2017-11-06 08:33:11 -08:00
Andy Brody 4b1c7a1d9b website: Fix broken link in 0.10 upgrade guide 2017-11-05 18:21:49 -08:00
Chris Marchesi 3fa11e456b
helper/schema: Clear existing map/set/list contents before overwriting
There are situations where one may need to write to a set, list, or map
more than once per single TF operation (apply/refresh/etc). In these
cases, further writes using Set (example: d.Set("some_set", newSet))
currently create unstable results in the set writer (the name of the
writer layer that holds the data set by these calls) because old keys
are not being cleared out first.

This bug is most visible when using sets. Example: First write to set
writes elements that have been hashed at 10 and 20, and the second write
writes elements that have been hashed at 30 and 40. While the set length
has been correctly set at 2, since a set is basically a map (as is the
entire map writer) and map results are non-deterministic, reads to this
set will now deliver unstable results in a random but predictable
fashion as the map results are delivered to the caller non-deterministic
- sometimes you may correctly get 30 and 40, but sometimes you may get
10 and 20, or even 10 and 30, etc.

This problem propagates to state which is even more damaging as unstable
results are set to state where they become part of the permanent data
set going forward.

The problem also applies to lists and maps. This is probably more of an
issue with maps as a map can contain any key/value combination and hence
there is no predictable pattern where keys would be overwritten with
default or zero values. This is contrary to complex lists, which has
this problem as well, but since lists are deterministic and the length
of a list properly gets updated during the overwrite, the problem is
masked by the fact that a read will only read to the boundary of the
list, skipping any bad data that may still be available due past the
list boundary.

This update clears the child contents of any set, list, or map before
beginning a new write to address this issue. Tests are included for all
three data types.
2017-11-05 12:04:23 -08:00
Martin Atkins 645df36af0 release: clean up after v0.11.0-beta1 2017-11-03 23:51:47 +00:00
Martin Atkins 23caaf9feb
v0.11.0-beta1 2017-11-03 23:17:07 +00:00
Martin Atkins 37e276e043 core: test correct behavior of plan+apply with unstable values
We have a few pesky functions that don't act like proper functions and
instead return different values on each call. These are tricky because
we need to make sure we don't trip over ourselves by re-generating these
between plan and apply.

Here we add a context test to verify correct behavior in the presence
of such functions.

There's actually a pre-existing bug which this test caught as originally
written: we re-evaluate the interpolation expressions during apply,
causing these unstable functions to produce new values, and so the
applied value ends up not exactly matching the plan. This is a bug that
needs fixing, but it's been around at least since v0.7.6 (random old
version I tried this with to see) so we'll put it on the list and address
it separately. For now, this part of the test is commented out with a
TODO attached.
2017-11-03 16:11:13 -07:00
Martin Atkins c003e8f9a6 core: don't compare attribute values in Diff.Same
We previously didn't compare values but had a TODO to start doing so,
which we then recently did. Unfortunately it turns out that we _depend_
on not comparing values here, because when we use EvalCompareDiff (a key
user of Diff.Same) we pass in a diff made from a fresh re-interpolation
of the configuration and so any non-pure function results (timestamp,
uuid) have produced different values.
2017-11-03 16:11:13 -07:00
Martin Atkins 46d2b76e5f
Update CHANGELOG.md 2017-11-03 12:20:53 -07:00
Martin Atkins 46a8deb8d1
Update CHANGELOG.md 2017-11-03 12:19:24 -07:00
Martin Atkins 3b180d7f8a
Merge #16543: Bring the "terraform" provider back into core 2017-11-03 12:08:31 -07:00
Martin Atkins d4ee58ce59 Re-integrate the "terraform" provider into the main binary
As part of the 0.10 core/provider split we moved this provider, along with
all the others, out into its own repository.

In retrospect, the "terraform" provider doesn't really make sense to be
separated since it's just a thin wrapper around some core code anyway,
and so re-integrating it into core avoids the confusion that results when
Terraform Core and the terraform provider have inconsistent versions of
the backend code and dependencies.

There is no good reason to use a different version of the backend code
in the provider than in core, so this new "internal provider" mechanism
is stricter than the old one: it's not possible to use an external build
of this provider at all, and version constraints for it are rejected as
a result.

This provider is also run in-process rather than in a child process, since
again it's just a very thin wrapper around code that's already running
in Terraform core anyway, and so the process barrier between the two does
not create enough advantage to warrant the additional complexity.
2017-11-03 11:36:31 -07:00
James Bardin f25d08061d
Merge pull request #16542 from hashicorp/jbardin/module-ui
update init output
2017-11-03 14:11:36 -04:00
Masayuki Morita 3efb163edd Update CHANGELOG.md 2017-11-03 08:14:38 -07:00
James Bardin 964054efc0 update tests for updated output 2017-11-03 11:13:31 -04:00
James Bardin f3470de2f0
Merge pull request #16546 from hashicorp/jbardin/mmissing-provider-transformer
further simplify the missing provider transformer
2017-11-03 11:01:56 -04:00
James Bardin 2ed529f81a update from review
Reference modules by terraform address
Unquote versions
2017-11-03 10:50:19 -04:00
James Bardin c510473fd2 remove code added by stale vim buffer 2017-11-03 10:33:18 -04:00
James Bardin 1bf64ec788 add "Updating" output and fix output tests 2017-11-03 10:28:08 -04:00
James Bardin 9c334fe012 update init output
Change "Downloading" to 'Initializing" to match the provider loading
dialog.

List each module being loaded.

If a regisry module is being downloaded, list the registry host, and the
version discovered.

Show the source string from the config that is being fetched, rather
than the go-getter url. The full source can be found in the logs for
debugging.

Add much more extensive logging
2017-11-03 10:28:07 -04:00
Paul Stack 002200b8f1 websites/workspaces: Add Manta to the list of workspace backends (#16545)
As Manta backend has now been merged, this should have been done in the same PR - apologises for that
2017-11-03 15:26:19 +01:00
James Bardin 9b489c452e further simplify the missing provider transformer
We can remove the AllowAny option which is no longer used, and providers
don't need to be connected to their resources at this stage, since that
will happen in the ProviderTransformer.
2017-11-03 10:26:03 -04:00
Tom Harvey 84d18ad579
Updating to include #16296 2017-11-03 15:20:49 +01:00
Tom Harvey 25c3a879db
Adding `azurerm` to the list of supported backends (#16531)
Fixes #16530
2017-11-03 14:57:43 +01:00
James Bardin 89b931e18a
Merge pull request #16540 from hashicorp/jbardin/provider-inheritance
New provider inheritance
2017-11-02 17:41:41 -04:00
James Bardin ecdba2b0b2 add transform step logs from GraphTransformMulti 2017-11-02 16:38:32 -04:00
James Bardin b4e9240679 remove implicit provier tests from config/module
No longer needed
2017-11-02 15:43:45 -04:00
James Bardin 523b121341 fix get test working directory
use a temp dir and cleanup
2017-11-02 15:38:53 -04:00
James Bardin 241dae7ead resintate disabled tests
Reinstate the disabled tests that required some sort of inheritance
during graph evaluation.
2017-11-02 15:29:51 -04:00
James Bardin 05ef30be2c udpate test graph outputs
Some of the test graph outputs have changes now that implicit providers
are no longer added in the config.
2017-11-02 15:29:51 -04:00