2014-05-24 14:04:43 -05:00
|
|
|
package terraform
|
|
|
|
|
|
|
|
// ResourceProvider is an interface that must be implemented by any
|
|
|
|
// resource provider: the thing that creates and manages the resources in
|
|
|
|
// a Terraform configuration.
|
|
|
|
type ResourceProvider interface {
|
2016-04-26 12:47:56 -05:00
|
|
|
/*********************************************************************
|
|
|
|
* Functions related to the provider
|
|
|
|
*********************************************************************/
|
|
|
|
|
2014-09-29 01:50:37 -05:00
|
|
|
// Input is called to ask the provider to ask the user for input
|
|
|
|
// for completing the configuration if necesarry.
|
|
|
|
//
|
|
|
|
// This may or may not be called, so resource provider writers shouldn't
|
|
|
|
// rely on this being available to set some default values for validate
|
|
|
|
// later. Example of a situation where this wouldn't be called is if
|
|
|
|
// the user is not using a TTY.
|
|
|
|
Input(UIInput, *ResourceConfig) (*ResourceConfig, error)
|
|
|
|
|
2014-06-13 00:30:09 -05:00
|
|
|
// Validate is called once at the beginning with the raw configuration
|
|
|
|
// (no interpolation done) and can return a list of warnings and/or
|
|
|
|
// errors.
|
|
|
|
//
|
2014-07-02 22:35:03 -05:00
|
|
|
// This is called once with the provider configuration only. It may not
|
|
|
|
// be called at all if no provider configuration is given.
|
|
|
|
//
|
2014-06-13 00:30:09 -05:00
|
|
|
// This should not assume that any values of the configurations are valid.
|
|
|
|
// The primary use case of this call is to check that required keys are
|
|
|
|
// set.
|
|
|
|
Validate(*ResourceConfig) ([]string, []error)
|
|
|
|
|
2014-05-24 14:04:43 -05:00
|
|
|
// Configure configures the provider itself with the configuration
|
|
|
|
// given. This is useful for setting things like access keys.
|
|
|
|
//
|
2014-07-02 22:35:03 -05:00
|
|
|
// This won't be called at all if no provider configuration is given.
|
|
|
|
//
|
2014-06-06 02:28:57 -05:00
|
|
|
// Configure returns an error if it occurred.
|
2014-06-12 19:59:59 -05:00
|
|
|
Configure(*ResourceConfig) error
|
2014-05-24 14:04:43 -05:00
|
|
|
|
|
|
|
// Resources returns all the available resource types that this provider
|
|
|
|
// knows how to manage.
|
2014-06-03 16:26:31 -05:00
|
|
|
Resources() []ResourceType
|
2014-06-03 18:42:21 -05:00
|
|
|
|
2016-04-26 12:47:56 -05:00
|
|
|
/*********************************************************************
|
|
|
|
* Functions related to individual resources
|
|
|
|
*********************************************************************/
|
|
|
|
|
|
|
|
// ValidateResource is called once at the beginning with the raw
|
|
|
|
// configuration (no interpolation done) and can return a list of warnings
|
|
|
|
// and/or errors.
|
|
|
|
//
|
|
|
|
// This is called once per resource.
|
|
|
|
//
|
|
|
|
// This should not assume any of the values in the resource configuration
|
|
|
|
// are valid since it is possible they have to be interpolated still.
|
|
|
|
// The primary use case of this call is to check that the required keys
|
|
|
|
// are set and that the general structure is correct.
|
|
|
|
ValidateResource(string, *ResourceConfig) ([]string, []error)
|
|
|
|
|
2014-06-03 18:42:21 -05:00
|
|
|
// Apply applies a diff to a specific resource and returns the new
|
|
|
|
// resource state along with an error.
|
|
|
|
//
|
|
|
|
// If the resource state given has an empty ID, then a new resource
|
|
|
|
// is expected to be created.
|
2014-06-18 17:35:03 -05:00
|
|
|
Apply(
|
2014-09-16 18:20:11 -05:00
|
|
|
*InstanceInfo,
|
|
|
|
*InstanceState,
|
2014-09-17 18:33:24 -05:00
|
|
|
*InstanceDiff) (*InstanceState, error)
|
2014-06-03 18:42:21 -05:00
|
|
|
|
|
|
|
// Diff diffs a resource versus a desired state and returns
|
|
|
|
// a diff.
|
|
|
|
Diff(
|
2014-09-16 18:20:11 -05:00
|
|
|
*InstanceInfo,
|
|
|
|
*InstanceState,
|
2014-09-17 18:33:24 -05:00
|
|
|
*ResourceConfig) (*InstanceDiff, error)
|
2014-06-19 23:22:07 -05:00
|
|
|
|
|
|
|
// Refresh refreshes a resource and updates all of its attributes
|
|
|
|
// with the latest information.
|
2014-09-16 18:20:11 -05:00
|
|
|
Refresh(*InstanceInfo, *InstanceState) (*InstanceState, error)
|
2016-04-26 12:47:56 -05:00
|
|
|
|
|
|
|
/*********************************************************************
|
|
|
|
* Functions related to importing
|
|
|
|
*********************************************************************/
|
|
|
|
|
2016-04-26 12:56:41 -05:00
|
|
|
// ImportState requests that the given resource be imported.
|
|
|
|
//
|
|
|
|
// The returned InstanceState only requires ID be set. Importing
|
|
|
|
// will always call Refresh after the state to complete it.
|
|
|
|
//
|
|
|
|
// IMPORTANT: InstanceState doesn't have the resource type attached
|
|
|
|
// to it. A type must be specified on the state via the Ephemeral
|
|
|
|
// field on the state.
|
|
|
|
//
|
|
|
|
// This function can return multiple states. Normally, an import
|
|
|
|
// will map 1:1 to a physical resource. However, some resources map
|
|
|
|
// to multiple. For example, an AWS security group may contain many rules.
|
|
|
|
// Each rule is represented by a separate resource in Terraform,
|
|
|
|
// therefore multiple states are returned.
|
2016-05-04 14:40:45 -05:00
|
|
|
ImportState(*InstanceInfo, string) ([]*InstanceState, error)
|
core: New ResourceProvider methods for data resources
This is a breaking change to the ResourceProvider interface that adds the
new operations relating to data sources.
DataSources, ValidateDataSource, ReadDataDiff and ReadDataApply are the
data source equivalents of Resources, Validate, Diff and Apply (respectively)
for managed resources.
The diff/apply model seems at first glance a rather strange workflow for
read-only resources, but implementing data resources in this way allows them
to fit cleanly into the standard plan/apply lifecycle in cases where the
configuration contains computed arguments and thus the read must be deferred
until apply time.
Along with breaking the interface, we also fix up the plugin client/server
and helper/schema implementations of it, which are all of the callers
used when provider plugins use helper/schema. This would be a breaking
change for any provider plugin that directly implements the provider
interface, but no known plugins do this and it is not recommended.
At the helper/schema layer the implementer sees ReadDataApply as a "Read",
as opposed to "Create" or "Update" as in the managed resource Apply
implementation. The planning mechanics are handled entirely within
helper/schema, so that complexity is hidden from the provider implementation
itself.
2016-05-07 23:55:32 -05:00
|
|
|
|
|
|
|
/*********************************************************************
|
|
|
|
* Functions related to data resources
|
|
|
|
*********************************************************************/
|
|
|
|
|
|
|
|
// ValidateDataSource is called once at the beginning with the raw
|
|
|
|
// configuration (no interpolation done) and can return a list of warnings
|
|
|
|
// and/or errors.
|
|
|
|
//
|
|
|
|
// This is called once per data source instance.
|
|
|
|
//
|
|
|
|
// This should not assume any of the values in the resource configuration
|
|
|
|
// are valid since it is possible they have to be interpolated still.
|
|
|
|
// The primary use case of this call is to check that the required keys
|
|
|
|
// are set and that the general structure is correct.
|
|
|
|
ValidateDataSource(string, *ResourceConfig) ([]string, []error)
|
|
|
|
|
|
|
|
// DataSources returns all of the available data sources that this
|
|
|
|
// provider implements.
|
|
|
|
DataSources() []DataSource
|
|
|
|
|
|
|
|
// ReadDataDiff produces a diff that represents the state that will
|
|
|
|
// be produced when the given data source is read using a later call
|
|
|
|
// to ReadDataApply.
|
|
|
|
ReadDataDiff(*InstanceInfo, *ResourceConfig) (*InstanceDiff, error)
|
|
|
|
|
|
|
|
// ReadDataApply initializes a data instance using the configuration
|
|
|
|
// in a diff produced by ReadDataDiff.
|
|
|
|
ReadDataApply(*InstanceInfo, *InstanceDiff) (*InstanceState, error)
|
2014-09-16 18:20:11 -05:00
|
|
|
}
|
|
|
|
|
2015-06-19 14:52:50 -05:00
|
|
|
// ResourceProviderCloser is an interface that providers that can close
|
|
|
|
// connections that aren't needed anymore must implement.
|
|
|
|
type ResourceProviderCloser interface {
|
|
|
|
Close() error
|
|
|
|
}
|
|
|
|
|
2014-05-24 14:04:43 -05:00
|
|
|
// ResourceType is a type of resource that a resource provider can manage.
|
|
|
|
type ResourceType struct {
|
2016-04-26 11:39:39 -05:00
|
|
|
Name string // Name of the resource, example "instance" (no provider prefix)
|
|
|
|
Importable bool // Whether this resource supports importing
|
2014-05-24 14:04:43 -05:00
|
|
|
}
|
2014-05-28 15:56:43 -05:00
|
|
|
|
core: New ResourceProvider methods for data resources
This is a breaking change to the ResourceProvider interface that adds the
new operations relating to data sources.
DataSources, ValidateDataSource, ReadDataDiff and ReadDataApply are the
data source equivalents of Resources, Validate, Diff and Apply (respectively)
for managed resources.
The diff/apply model seems at first glance a rather strange workflow for
read-only resources, but implementing data resources in this way allows them
to fit cleanly into the standard plan/apply lifecycle in cases where the
configuration contains computed arguments and thus the read must be deferred
until apply time.
Along with breaking the interface, we also fix up the plugin client/server
and helper/schema implementations of it, which are all of the callers
used when provider plugins use helper/schema. This would be a breaking
change for any provider plugin that directly implements the provider
interface, but no known plugins do this and it is not recommended.
At the helper/schema layer the implementer sees ReadDataApply as a "Read",
as opposed to "Create" or "Update" as in the managed resource Apply
implementation. The planning mechanics are handled entirely within
helper/schema, so that complexity is hidden from the provider implementation
itself.
2016-05-07 23:55:32 -05:00
|
|
|
// DataSource is a data source that a resource provider implements.
|
|
|
|
type DataSource struct {
|
|
|
|
Name string
|
|
|
|
}
|
|
|
|
|
2014-05-28 15:56:43 -05:00
|
|
|
// ResourceProviderFactory is a function type that creates a new instance
|
|
|
|
// of a resource provider.
|
|
|
|
type ResourceProviderFactory func() (ResourceProvider, error)
|
2014-06-03 17:08:00 -05:00
|
|
|
|
2014-07-10 11:46:21 -05:00
|
|
|
// ResourceProviderFactoryFixed is a helper that creates a
|
|
|
|
// ResourceProviderFactory that just returns some fixed provider.
|
|
|
|
func ResourceProviderFactoryFixed(p ResourceProvider) ResourceProviderFactory {
|
|
|
|
return func() (ResourceProvider, error) {
|
|
|
|
return p, nil
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
core: New ResourceProvider methods for data resources
This is a breaking change to the ResourceProvider interface that adds the
new operations relating to data sources.
DataSources, ValidateDataSource, ReadDataDiff and ReadDataApply are the
data source equivalents of Resources, Validate, Diff and Apply (respectively)
for managed resources.
The diff/apply model seems at first glance a rather strange workflow for
read-only resources, but implementing data resources in this way allows them
to fit cleanly into the standard plan/apply lifecycle in cases where the
configuration contains computed arguments and thus the read must be deferred
until apply time.
Along with breaking the interface, we also fix up the plugin client/server
and helper/schema implementations of it, which are all of the callers
used when provider plugins use helper/schema. This would be a breaking
change for any provider plugin that directly implements the provider
interface, but no known plugins do this and it is not recommended.
At the helper/schema layer the implementer sees ReadDataApply as a "Read",
as opposed to "Create" or "Update" as in the managed resource Apply
implementation. The planning mechanics are handled entirely within
helper/schema, so that complexity is hidden from the provider implementation
itself.
2016-05-07 23:55:32 -05:00
|
|
|
func ProviderHasResource(p ResourceProvider, n string) bool {
|
2014-06-03 17:08:00 -05:00
|
|
|
for _, rt := range p.Resources() {
|
|
|
|
if rt.Name == n {
|
|
|
|
return true
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return false
|
|
|
|
}
|
core: New ResourceProvider methods for data resources
This is a breaking change to the ResourceProvider interface that adds the
new operations relating to data sources.
DataSources, ValidateDataSource, ReadDataDiff and ReadDataApply are the
data source equivalents of Resources, Validate, Diff and Apply (respectively)
for managed resources.
The diff/apply model seems at first glance a rather strange workflow for
read-only resources, but implementing data resources in this way allows them
to fit cleanly into the standard plan/apply lifecycle in cases where the
configuration contains computed arguments and thus the read must be deferred
until apply time.
Along with breaking the interface, we also fix up the plugin client/server
and helper/schema implementations of it, which are all of the callers
used when provider plugins use helper/schema. This would be a breaking
change for any provider plugin that directly implements the provider
interface, but no known plugins do this and it is not recommended.
At the helper/schema layer the implementer sees ReadDataApply as a "Read",
as opposed to "Create" or "Update" as in the managed resource Apply
implementation. The planning mechanics are handled entirely within
helper/schema, so that complexity is hidden from the provider implementation
itself.
2016-05-07 23:55:32 -05:00
|
|
|
|
|
|
|
func ProviderHasDataSource(p ResourceProvider, n string) bool {
|
|
|
|
for _, rt := range p.DataSources() {
|
|
|
|
if rt.Name == n {
|
|
|
|
return true
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return false
|
|
|
|
}
|