Commit Graph

19820 Commits

Author SHA1 Message Date
Martin Atkins 9a398a7793 command: require resource to be in config before import
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.
2017-06-09 14:03:59 -07:00
Martin Atkins 7d8719150c command: validate import resource address early
Previously we deferred validation of the resource address on the import
command until we were in the core guts, which caused the error responses
to be rather unhelpful.

By validating these things early we can give better feedback to the user.
2017-06-09 14:03:59 -07:00
Martin Atkins f6305fcc27 command: remove commented-out, misplaced tests
For some reason there was a block of commented-out tests for the refresh
command in the test file for the import command. Here we remove them to
reduce the noise in this file.
2017-06-09 14:03:59 -07:00
Martin Atkins 190626e2a8 core: improve consistency of ParseResourceAddress errors
Previously one of the errors had a built-in context message and the other
did not, making it hard for callers to present a user-friendly message
in both cases.

Now we generate an error message of the same form in both cases, with one
case providing additional information. Ideally the main case would be
able to give more specific guidance too, but that's hard to achieve with
the current regexp-based parsing implementation.
2017-06-09 14:03:59 -07:00
Martin Atkins b82ef2e30e core: ResourceAddress.MatchesConfig method
This is a useful building block for filtering configuration based on a
resource address. It is similar in principle to state filtering, but for
specific resource configuration blocks.
2017-06-09 14:03:59 -07:00
Martin Atkins f695e8b330 provider/test: allow test_resource to be imported
When working on the core import code, it's useful to have a zero-cost
local resource to work with for quick iteration.
2017-06-09 14:03:59 -07:00
Martin Atkins edf3cd7159 core: ResourceAddress.WholeModuleAddress method
This allows growing the scope of a resource address to include all of the
resources in the same module as the targeted resource. This is useful to
give context in error messages.
2017-06-09 14:03:59 -07:00
Martin Atkins 05a5eb0047 core: ResourceAddress.HasResourceSpec method
The resource address documentation defines a resource address as being in
two parts: the module path and the resource spec. The resource spec can
be omitted, which represents addressing _all_ resources in a module.

In some cases (such as import) it doesn't make sense to address an entire
module, so this helper makes it easy for validation code to check for
this to reject insufficiently-specific resource addresses.
2017-06-09 14:03:59 -07:00
James Bardin 044ad5ef59 rename some Constraints methods per code review 2017-06-09 14:03:59 -07:00
James Bardin 211f5b5d6e add test for newestVersion 2017-06-09 14:03:59 -07:00
James Bardin 46190590cb change []*Version to []Version
Versions are used as values, so don't keep them as pointers here
2017-06-09 14:03:59 -07:00
James Bardin a547e7c2f0 add releases version listing test 2017-06-09 14:03:59 -07:00
James Bardin 2994c6ac5d add init getPlugin test
add a mock plugin getter, and test that we can fetch requested version
of the plugins.
2017-06-09 14:03:59 -07:00
James Bardin 4c32cd432a make getProvider pluggable 2017-06-09 14:03:59 -07:00
James Bardin 66ebff90cd move some more plugin search path logic to command
Make less to change when we remove the old search path
2017-06-09 14:03:59 -07:00
James Bardin 2749946f5c basic plugin getter
Add discovery.GetProviders to fetch plugins from the relases site.

This is an early version, with no tests, that only (probably) fetches
plugins from the default location. The URLs are still subject to change,
and since there are no plugin releases, it doesn't work at all yet.
2017-06-09 14:03:59 -07:00
James Bardin fa49c69793 expose Version.NewerThan
NewerThan is useful outside of the package
2017-06-09 14:03:59 -07:00
James Bardin 7d2d951f27 Rename VersionSet to Constraints
VersionSet is a wrapper around version.Contraints, so rename it it as
such.
2017-06-09 14:03:59 -07:00
James Bardin 718ede0636 have Meta.Backend use a Config rather than loading
Instead of providing the a path in BackendOpts, provide a loaded
*config.Config instead. This reduces the number of places where
configuration is loaded.
2017-06-09 14:03:59 -07:00
Martin Atkins d7d8ea9543 website: Initial docs for the new "providers" subcommand
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.
2017-06-09 14:03:59 -07:00
Martin Atkins 3af0ecdf01 command: "terraform providers" command
This new command prints out the tree of modules annotated with their
associated required providers.

The purpose of this command is to help users answer questions such as
"why is this provider required?", "why is Terraform using an older version
of this provider?", and "what combination of modules is creating an
impossible provider version situation?"

For configurations using many modules this sort of question is likely to
come up a lot once we support versioned providers.

As a bonus use-case, this command also shows explicitly when a provider
configuration is being inherited from a parent module, to help users to
understand where the configuration is coming from for each module when
some child modules provide their own provider configurations.
2017-06-09 14:03:59 -07:00
Martin Atkins 8b037432e7 vendoring of treeprint library 2017-06-09 14:03:59 -07:00
Martin Atkins ccb3a7c584 core: expose terraform.ModuleTreeDependencies as a public function
This is a generally-useful utility for computing dependency trees, so no
reason to restrict it to just the terraform package.
2017-06-09 14:03:59 -07:00
Martin Atkins 4ab8973520 core: provide config to all import context tests
We're going to use config to determine provider dependencies, so we need
to always provide a config when instantiating a context or we'll end up
loading no providers at all.

We previously had a test for running "terraform import -config=''" to
disable the config entirely, but this test is now removed because it makes
no sense. The actual functionality its testing still remains for now,
but it will be removed in a subsequent commit when we start requiring that
a resource to be imported must already exist in configuration.
2017-06-09 14:03:59 -07:00
Martin Atkins c835ef8ff3 Update tests for the new ProviderResolver interface
Rather than providing an already-resolved map of plugins to core, we now
provide a "provider resolver" which knows how to resolve a set of provider
dependencies, to be determined later, and produce that map.

This requires the context to be instantiated in a different way, so this
very noisy diff is a mostly-mechanical update of all of the existing
places where contexts get created for testing, using some adapted versions
of the pre-existing utilities for passing in mock providers.
2017-06-09 14:03:59 -07:00
Martin Atkins 7ca592ac06 core: use ResourceProviderResolver to resolve providers
Previously the set of providers was fixed early on in the command package
processing. In order to be version-aware we need to defer this work until
later, so this interface exists so we can hold on to the possibly-many
versions of plugins we have available and then later, once we've finished
determining the provider dependencies, select the appropriate version of
each provider to produce the final set of providers to use.

This commit establishes the use of this new mechanism, and thus populates
the provider factory map with only the providers that result from the
dependency resolution process.

This disables support for internal provider plugins, though the
mechanisms for building and launching these are still here vestigially,
to be cleaned up in a subsequent commit.

This also adds a new awkward quirk to the "terraform import" workflow
where one can't import a resource from a provider that isn't already
mentioned (implicitly or explicitly) in config. We will do some UX work
in subsequent commits to make this behavior better.

This breaks many tests due to the change in interface, but to keep this
particular diff reasonably easy to read the test fixes are split into
a separate commit.
2017-06-09 14:03:59 -07:00
Martin Atkins ba3ee00837 core: ResourceProviderResolver interface
ResourceProviderResolver is an extra level of indirection before we
get to a map[string]ResourceProviderFactory, which accepts a map of
version constraints and uses it to choose from potentially-many available
versions of each provider to produce a single ResourceProviderFactory
for each one requested.

As of this commit the ResourceProviderResolver interface is not used. In
a future commit the ContextOpts.Providers map will be replaced with a
resolver instance, with the creation of the factory delayed until the
version constraints have been resolved.
2017-06-09 14:03:59 -07:00
Martin Atkins d6b6dbb5c6 command: correct provider name in the test fixture for push
Currently this doesn't matter much, but we're about to start checking the
availability of providers early on and so we need to use the correct name
for the mock set of providers we use in command tests, which includes
only a provider named "test".

Without this change, the "push" tests will begin failing once we start
verifying this, since there's no "aws" provider available in the test
context.
2017-06-09 14:03:59 -07:00
Martin Atkins 0573ff6793 helper/resource: pass config when testing import
Previously having a config was mutually exclusive with running an import,
but we need to provide a config so that the provider is declared, or else
we can't actually complete the import in the future world where providers
are installed dynamically based on their declarations.
2017-06-09 14:03:59 -07:00
Martin Atkins 1c0b715999 core: return explicit caption if tests fail to construct context
The previous error was very generic, making it hard to quickly tell from
the test output that the error was during context initialization.
2017-06-09 14:03:59 -07:00
Martin Atkins 8bfc6e7b1c core: add missing ResourceState types in context tests
Previously the Type of a ResourceState was generally ignored, but we're
now starting to use it to figure out which providers are needed to
support the resources in state so our tests need to set it accurately
in order to get the expected result.
2017-06-09 14:03:59 -07:00
Martin Atkins 25a6d8f471 core: build a module dependency tree from config+state
This new private function takes a configuration tree and a state structure
and finds all of the explicit and implied provider dependencies
represented, returning them as a moduledeps.Module tree structure.

It annotates each dependency with a "reason", which is intended to be
useful to a user trying to figure out where a particular dependency is
coming from, though we don't yet have any UI to view this.

Nothing calls this yet, but a subsequent commit will use the result of
this to produce a constraint-conforming map of provider factories during
context initialization.
2017-06-09 14:03:59 -07:00
Martin Atkins c20f25a10e moduledeps: Module.Equals
Compares two modules for deep equality. This is primarily provided to
enable easy testing of code that constructs module tree structures.
2017-06-09 14:03:59 -07:00
Martin Atkins cfc08ae7e3 plugin/discovery: provide an AllVersions set
Various implied dependencies will accept all versions, so this is
convenient for populating dependency data structures for such implied
dependencies.
2017-06-09 14:03:59 -07:00
Martin Atkins e89b5390ca moduledeps: new package for representing module dependencies
As we add support for versioned providers, it's getting more complex to
track the dependencies of each module and of the configuration as a whole,
so this new package is intended to give us some room to model that
nicely as a building block for the various aspects of dependency
management.

This package is not responsible for *building* the dependency data
structure, since that requires knowledge of core Terraform and that would
create cyclic package dependencies. A later change will add some logic
in Terraform to create a Module tree based on the combination of a given
configuration and state, returning an instance of this package's Module
type.

The Module.PluginRequirements method flattens the provider-oriented
requirements into a set of plugin-oriented requirements (flattening any
provider aliases) giving us what we need to work with the plugin/discovery
package to find matching installed plugins.

Other later uses of this package will include selecting plugin archives
to auto-install from releases.hashicorp.com as part of "terraform init",
where the module-oriented level of abstraction here should be useful for
giving users good, specific feedback when constraints cannot be met.

A "reason" is tracked for each provider dependency with the intent that
this would later drive a UI for users to see and understand why a given
dependency is present, to aid in debugging sticky issues with
dependency resolution.
2017-06-09 14:03:59 -07:00
Martin Atkins a1e29ae290 plugin/discovery: use go-version instead of semver
The semver library we were using doesn't have support for a "pessimistic
constraint" where e.g. the user wants to accept only minor or patch
version upgrades. This is important for providers since users will
generally want to pin their dependencies to not inadvertantly accept
breaking changes.

So here we switch to hashicorp's home-grown go-version library, which
has the ~> constraint operator for this sort of constraint.

Given how much the old version object was already intruding into the
interface and creating dependency noise in callers, this also now wraps
the "raw" go-version objects in package-local structs, thus keeping the
details encapsulated and allowing callers to deal just with this package's
own types.
2017-06-09 14:03:59 -07:00
Martin Atkins a8a64c66c0 config/module: helper to visit all modules in a tree 2017-06-09 14:03:59 -07:00
Martin Atkins 32a5c62639 config: parse provider version constraints into a constraint map 2017-06-09 14:03:59 -07:00
Martin Atkins 0b14c2cdb3 Resolve resource provider types in config package
Previously the logic for inferring a provider type from a resource name
was buried a utility function in the 'terraform' package. Instead here we
lift it up into the 'config' package where we can make broader use of it
and where it's easier to discover.
2017-06-09 14:03:59 -07:00
Martin Atkins 7e7d4c70df config: allow version constraints on providers, but validate them
We now accept syntactically-valid version constraints on provider blocks,
though we still don't actually do anything with them.
2017-06-09 14:03:59 -07:00
Martin Atkins 9b4f15c261 plugin: move Client function into plugin, from plugin/discovery
Having this as a method of PluginMeta felt most natural, but unfortunately
that means that discovery must depend on plugin and plugin in turn
depends on core Terraform, thus making the discovery package hard to use
without creating dependency cycles.

To resolve this, we invert the dependency and make the plugin package be
responsible for instantiating clients given a meta, using a top-level
function.
2017-06-09 14:03:59 -07:00
Martin Atkins 73fc9985b2 config: add "version" argument to provider blocks, disabled
In future we will support version constraints on providers, so we're
reserving this attribute name that is currently not used by any builtin
providers.

For now using this will produce an error, since the rest of Terraform
(outside of the config parser) doesn't currently have this notion and we
don't want people to start trying to use it until its behavior is fully
defined and implemented.

It may be used by third-party providers, so this is a breaking change
worth warning about in CHANGELOG but one whose impact should be small.
Any third-party providers using this name should migrate to using a new
attribute name instead moving forward.
2017-06-09 14:03:59 -07:00
Martin Atkins 8364383c35 Push plugin discovery down into command package
Previously we did plugin discovery in the main package, but as we move
towards versioned plugins we need more information available in order to
resolve plugins, so we move this responsibility into the command package
itself.

For the moment this is just preserving the existing behavior as long as
there are only internal and unversioned plugins present. This is the
final state for provisioners in 0.10, since we don't want to support
versioned provisioners yet. For providers this is just a checkpoint along
the way, since further work is required to apply version constraints from
configuration and support additional plugin search directories.

The automatic plugin discovery behavior is not desirable for tests because
we want to mock the plugins there, so we add a new backdoor for the tests
to use to skip the plugin discovery and just provide their own mock
implementations. Most of this diff is thus noisy rework of the tests to
use this new mechanism.
2017-06-09 14:03:59 -07:00
Martin Atkins bcd395e6bd plugin/discovery: Allow overriding the paths of certain plugin names
The .terraformrc file allows the user to override the executable location
for certain plugins. This mechanism allows us to retain that behavior for
a deprecation period by treating such executables as an unversioned
plugin for the given name and excluding all other candidates for that
name, thus ensuring that the override will "win".

Users must eventually transition away from using this mechanism and use
vendor directories instead, because these unversioned overrides will never
match for a provider referenced with non-zero version constraints.
2017-06-09 14:03:59 -07:00
Martin Atkins 551bc9c4a4 plugin/discovery: build plugin clients
These new methods ClientConfig and Client provide the bridge into the
main plugin infrastructure by configuring and instantiating (respectively)
a client object for the referenced plugin.

This stops short of getting the proxy object from the client since that
then requires referencing the interface for the plugin kind, which would
then create a dependency on the main terraform package which we'd rather
avoid here. It'll be the responsibility of the caller in the command
package to do the final wiring to get a provider instance out of a
provider plugin client.
2017-06-09 14:03:59 -07:00
Martin Atkins 0a08214a74 plugin/discovery: SHA256() method to get the hash of each plugin
This will be used later to verify that installed plugins match what's
available on the releases server.
2017-06-09 14:03:59 -07:00
Martin Atkins a94e9a4362 plugin/discovery: find plugins in a given set of directories
For now this supports both our old and new directory layouts, so we can
preserve compatibility with existing configurations until a future major
release where support for the old paths will be removed.

Currently this allows both styles in all given directories, which means we
support more variants than we actually intend to but this is accepted to
keep the interface simple such that we can easily remove the legacy
exception later. The documentation will reflect only the subset of
path layouts that we actually intend to support.
2017-06-09 14:03:59 -07:00
Martin Atkins 39deb1ff6b plugin/discovery: helpers for wrangling plugin versions
With forthcoming support for versioned plugins we need to be able to
answer questions like what versions of plugins are currently installed,
what's the newest version of a given plugin available, etc.

PluginMetaSet gives us a building block for this sort of plugin version
wrangling.
2017-06-09 14:03:59 -07:00
Paul Stack f69f7e623b Create CHANGELOG.md 2017-06-09 14:14:31 +03:00
stack72 6e7ee05392 Merge branch 'gh3424-vgw-route-prop' 2017-06-09 14:13:27 +03:00