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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
* Data Source support for Resource Group
* Better message for mismatching locations.
* Reuse existing read code
* Adds documentation
* Adds test
* Adds a function for composing ID strings
* Change location to computed.
* initial commit - 101-vm-from-user-image
* changed branch name
* not deploying - storage problems
* provisions vm but image not properly prepared
* storage not correct
* provisions properly
* changed main.tf to azuredeploy.tf
* added tfvars and info for README
* tfvars ignored and corrected file ext
* added CI config; added sane defaults for variables; updated deployment script, added mac specific deployment for local testing
* deploy.sh to be executable
* executable deploy files
* added CI files; changed vars
* prep for PR
* removal of old folder
* prep for PR
* wrong args for travis
* more PR prep
* updated README
* commented out variables in terraform.tfvars
* Topic 101 vm from user image (#2)
* initial commit - 101-vm-from-user-image
* added tfvars and info for README
* added CI config; added sane defaults for variables; updated deployment script, added mac specific deployment for local testing
* prep for PR
* added new template
* oops, left off master
* prep for PR
* correct repository for destination
* renamed scripts to be more intuitive; added check for docker
* merge vm simple; vm from image
* initial commit
* deploys locally
* updated deploy
* consolidated deploy and after_deploy into a single script; simplified ci process; added os_profile_linux_config
* added terraform show
* changed to allow http & https (like ARM tmplt)
* changed host_name & host_name variable desc
* added az cli check
* on this branch, only build test_dir; master will aggregate all the examples
* merge master
* added new constructs/naming for deploy scripts, etc.
* suppress az login output
* suppress az login output
* forgot about line breaks
* breaking build as an example
* fixing broken build example
* merge of CI config
* fixed grammar in readme
* prep for PR
* took out armviz button and minor README changes
* changed host_name
* fixed merge conflicts
* changed host_name variable
* updating Hashicorp's changes to merged simple linux branch
* updating files to merge w/master and prep for Hashicorp pr
* Revert "updating files to merge w/master and prep for Hashicorp pr"
This reverts commit b850cd5d2a858eff073fc5a1097a6813d0f8b362.
* Revert "updating Hashicorp's changes to merged simple linux branch"
This reverts commit dbaf8d14a9cdfcef0281919671357f6171ebd4e6.
* removing vm from user image example from this branch
* removed old branch
* azure-2-vms-loadbalancer-lbrules (#13)
* initial commit
* need to change lb_rule & nic
* deploys locally
* updated README
* updated travis and deploy scripts for Hari's repo
* renamed deploy script
* clean up
* prep for PR
* updated readme
* fixing conflict in .travis.yml
* initial commit; in progress
* in progress
* in progress; encryption fails
* in progress
* deploys successfully locally
* clean up; deploy typo fixed
* merging hashi master into this branch
* troubleshooting deploy
* added missing vars to deploy script
* updated README, outputs, and added graph
* simplified outputs
* provisions locally
* cleaned up vars
* fixed chart on README
* prepping for pr
* fixed merge conflict
* switching to Hashicorp's .travis.yml
* edited comments
* removed graph
* reverting travis.yml to original
added return line at 45
* Move to v2 client in vendor directory
* Move to v2 api and project IDs for environments
* add host label support to registration command
* Update go-rancher/catalog
* Allow go-rancher to handle URL versioning
Martin Atkins