Commit Graph

19736 Commits

Author SHA1 Message Date
Martin Atkins 9aae06db97 command: update mockGetProvider.GetProvider for new interface
The expected type was changed in the mainline code but the tests were not
updated to match.
2017-06-09 14:03:59 -07:00
Martin Atkins 4ba20f9c1c command init: show suggested constraints for unconstrained providers
When running "terraform init" with providers that are unconstrained, we
will now produce information to help the user update configuration to
constrain for the particular providers that were chosen, to prevent
inadvertently drifting onto a newer major release that might contain
breaking changes.

A ~> constraint is used here because pinning to a single specific version
is expected to create dependency hell when using child modules. By using
this constraint mode, which allows minor version upgrades, we avoid the
need for users to constantly adjust version constraints across many
modules, but make major version upgrades still be opt-in.

Any constraint at all in the configuration will prevent the display of
these suggestions, so users are free to use stronger or weaker constraints
if desired, ignoring the recommendation.
2017-06-09 14:03:59 -07:00
Martin Atkins f70318097a config: fix provider version constraint validation
Previously we were using the "semver" library to parse version
constraints, but we switched over to go-version and encapsulated it
inside our own plugin/discovery package to reduce dependency sprawl in
the code.

This particular situation was missed when updating references to the new
path, which meant that our validation code disagreed with the rest of
the code about what is considered a valid version constraint string.
By using the correct function, we ensure that we catch early any invalid
versions.
2017-06-09 14:03:59 -07:00
James Bardin dbbafbd43f clean up plugin fetching
We can filter the allowed versions and sort them before checking the
protocol version, that way we can just return the first one found
reducing network requests.
2017-06-09 14:03:59 -07:00
James Bardin e0f2235f66 update init command with new GetProvider signature
GetProvider needs the plugin protocol version to be passed in
2017-06-09 14:03:59 -07:00
James Bardin 48d37131e0 more tests for fetching providers
Extend the test reslease server to return the protocol version header
and a dummy zip file for the provider.

Test filtering the plugins by plugin protocol version and add a full
GetProvder test.
2017-06-09 14:03:59 -07:00
James Bardin 5f053a2e64 refactor GetProvider
Get provider needs to be provided with the plugin protocol version,
because it can't be imported here directly.

The plugin url types and methods were confusing; replace them with a few
functions to format the urls.
2017-06-09 14:03:59 -07:00
James Bardin 8ad67991a5 check protocol version on plugins
Verify that the plugin we're requesting has a compatible protocol
version.
2017-06-09 14:03:59 -07:00
James Bardin fdeb3d929c Add Versions.Sort
Sort versions from newest to oldest.
2017-06-09 14:03:59 -07:00
Martin Atkins 032f71f1ff command: produce provider lock file during "terraform init"
Once we've installed the necessary plugins, we'll do one more walk of
the available plugins and record the SHA256 hashes of all of the plugins
we select in the provider lock file.

The file we write here gets read when we're building ContextOpts to
initialize the main terraform context, so any command that works with
the context will then fail if any of the provider binaries change.
2017-06-09 14:03:59 -07:00
Martin Atkins 04bcece59c plugin/discovery: handle the -Xn suffix used by auto-installed plugins
This is used to mark the plugin protocol version. Currently we actually
just ignore this entirely, since only one protocol version exists anyway.
Later we will need to add checks here to ensure that we only pay attention
to plugins of the right version.
2017-06-09 14:03:59 -07:00
Martin Atkins 6ba6508ec9 command: pass the locked plugin hashes into ContextOpts
By reading our lock file and passing this into the context, we ensure that
only the plugins referenced in the lock file can be used. As of this
commit there is no way to create that lock file, but that will follow soon
as part of "terraform init".

We also provide a way to force a particular set of SHA256s. The main use
for this is to allow us to persist a set of plugins in the plan and
check the same plugins are used during apply, but it may also be useful
for automated tests.
2017-06-09 14:03:59 -07:00
Martin Atkins aa1c644499 core: allow setting required plugin hashes on Context
When set, this information gets passed on to the provider resolver as
part of the requirements information, causing us to reject any plugins
that do not match during initialization.
2017-06-09 14:03:59 -07:00
Martin Atkins 720670fae7 command: helper to manage the provider plugins lock file
This is just a JSON file with the SHA256 digests of the plugin
executables.
2017-06-09 14:03:59 -07:00
Martin Atkins 7d0a98af46 command: provider resolver to also check SHA256 constraints when set
In addition to looking for matching versions, the caller can also
optionally require a specific executable by its SHA256 digest.
2017-06-09 14:03:59 -07:00
Martin Atkins e3401947a6 plugin/discovery: PluginRequirements can specify SHA256 digests
As well as constraining plugins by version number, we also want to be
able to pin plugins to use specific executables so that we can detect
drift in available plugins between commands.

This commit allows such requirements to be specified, but doesn't yet
specify any such requirements, nor validate them.
2017-06-09 14:03:59 -07:00
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