Commit Graph

24 Commits

Author SHA1 Message Date
Kristin Laemmert ff05362d51
providers.Interface: rename ValidateDataSourceConfig to ValidateDataResourceConfig (#27874)
* providers.Interface: rename ValidateDataSourceConfig to
ValidateDataResourceConfig

This PR came about after renaming ValidateResourceTypeConfig to
ValidateResourceConfig: I now understand that we'd called it the former
instead of the latter to indicate that the function wasn't necessarily
operating on a resource that actually exists. A possibly-more-accurate
renaming of both functions might then be ValidateManagedResourceConfig
and ValidateDataResourceConfig.

The next commit will update the protocol (v6 only) as well; these are in
separate commits for reviewers and will get squashed together before
merging.

* extend renaming to protov6
2021-02-24 12:04:28 -05:00
Kristin Laemmert f6505870cc
Mildwonkey/providers interface renaming (#27805)
* providers.Interface: huge renamification

This commit renames a handful of functions in the providers.Interface to
match changes made in protocol v6. The following commit implements this
change across the rest of the codebase; I put this in a separate commit
for ease of reviewing and will squash these together when merging.

One noteworthy detail: protocol v6 removes the config from the
ValidateProviderConfigResponse, since it's never been used. I chose to
leave that in place in the interface until we deprecate support for
protocol v5 entirely.

Note that none of these changes impact current providers using protocol
v5; the protocol is unchanged. Only the translation layer between the
proto and terraform have changed.
2021-02-18 10:13:43 -05:00
James Bardin 73680546a8 udpate PrepareProviderConfig docs
Indicate that the PreparedConfig is not used by core.
2020-11-04 13:02:04 -05:00
Pam Selle 0a02e7040f
Store sensitive attribute paths in state (#26338)
* Add creation test and simplify in-place test

* Add deletion test

* Start adding marking from state

Start storing paths that should be marked
when pulled out of state. Implements deep
copy for attr paths. This commit also includes some
comment noise from investigations, and fixing the diff test

* Fix apply stripping marks

* Expand diff tests

* Basic apply test

* Update comments on equality checks to clarify current understanding

* Add JSON serialization for sensitive paths

We need to serialize a slice of cty.Path values to be used to re-mark
the sensitive values of a resource instance when loading the state file.
Paths consist of a list of steps, each of which may be either getting an
attribute value by name, or indexing into a collection by string or
number.

To serialize these without building a complex parser for a compact
string form, we render a nested array of small objects, like so:

[
  [
    { type: "get_attr", value: "foo" },
    { type: "index", value: { "type": "number", "value": 2 } }
  ]
]

The above example is equivalent to a path `foo[2]`.

* Format diffs with map types

Comparisons need unmarked values to operate on,
so create unmarked values for those operations. Additionally,
change diff to cover map types

* Remove debugging printing

* Fix bug with marking non-sensitive values

When pulling a sensitive value from state,
we were previously using those marks to remark
the planned new value, but that new value
might *not* be sensitive, so let's not do that

* Fix apply test

Apply was not passing the second state
through to the third pass at apply

* Consistency in checking for length of paths vs inspecting into value

* In apply, don't mark with before paths

* AttrPaths test coverage for DeepCopy

* Revert format changes

Reverts format changes in format/diff for this
branch so those changes can be discussed on a separate PR

* Refactor name of AttrPaths to AttrSensitivePaths

* Rename AttributePaths/attributePaths for naming consistency

Co-authored-by: Alisdair McDiarmid <alisdair@users.noreply.github.com>
2020-09-24 12:40:17 -04:00
Paddy e6592dc710
Add support for provider metadata to modules. (#22583)
Implement a new provider_meta block in the terraform block of modules, allowing provider-keyed metadata to be communicated from HCL to provider binaries.

Bundled in this change for minimal protocol version bumping is the addition of markdown support for attribute descriptions and the ability to indicate when an attribute is deprecated, so this information can be shown in the schema dump.

Co-authored-by: Paul Tyng <paul@paultyng.net>
2020-03-05 16:53:24 -08:00
James Bardin dcab82e897 send and receive Private through ReadResource
Send Private data blob through ReadResource as well. This will allow for
extra flexibility for future providers that may want to pass data out of
band through to their resource Read functions.
2019-06-03 18:08:26 -04:00
Martin Atkins 31299e688d core: Allow legacy SDK to opt out of plan-time safety checks
Due to the inprecision of our shimming from the legacy SDK type system to
the new Terraform Core type system, the legacy SDK produces a number of
inconsistencies that produce only minor quirky behavior or broken
edge-cases. To retain compatibility with those existing weird behaviors,
the legacy SDK opts out of our safety checks.

The intent here is to allow existing providers to continue to do their
previous unsafe behaviors for now, accepting that this will allow certain
quirky bugs from previous releases to persist, and then gradually migrate
away from the legacy SDK and remove this opt-out on a per-resource basis
over time.

As with the apply-time safety check opt-out, this is reserved only for
the legacy SDK and must not be used in any new SDK implementations. We
still include any inconsistencies as warnings in the logs as an aid to
anyone debugging weird behavior, so that they can see situations where
blame may be misplaced in the user-visible error messages.
2019-02-11 17:26:49 -08:00
Martin Atkins 1530fe52f7 core: Legacy SDK providers opt out of our new apply result check
The shim layer for the legacy SDK type system is not precise enough to
guarantee it will produce identical results between plan and apply. In
particular, values that are null during plan will often become zero-valued
during apply.

To avoid breaking those existing providers while still allowing us to
introduce this check in the future, we'll introduce a rather-hacky new
flag that allows the legacy SDK to signal that it is the legacy SDK and
thus disable the check.

Once we start phasing out the legacy SDK in favor of one that natively
understands our new type system, we can stop setting this flag and thus
get the additional safety of this check without breaking any
previously-released providers.

No other SDK is permitted to set this flag, and we will remove it if we
ever introduce protocol version 6 in future, assuming that any provider
supporting that protocol will always produce consistent results.
2019-02-06 11:40:30 -08:00
Martin Atkins 72e279e6b2 providers: Consistently use int64 for schema versions
The rest of Terraform is still using uint64 for this in various spots, but
we'll update that gradually later. We use int64 here because that matches
what's used in our protobuf definition, and unsigned integers are not
portable across all of the protobuf target languages anyway.
2018-11-30 11:22:39 -08:00
James Bardin c1303f8482 providers PrepareProviderConfig
Change ValidateProviderConfig to PrepareProviderConfig.

Providers have a concept of "required fields with defaults" that that
was handled previously by helper/schema doing input and validation.
Because Input and Validation is mostly now handled by core, the provider
had no way of setting default values for missing required attributes.

To achieve the same behavior with new providers, there will be a
PrepareProviderConfig, which allow for manual validation, as well as
alteration of the config. The provider is free to set whatever
attributes necessary to create a valid config and return it to the
caller. If a new config is returned, it will be used instead of the
original in the subsequent Configure call, however core may still add
missing required values during an optional Input phase.
2018-10-17 21:31:52 -04:00
Martin Atkins 44bc7519a6 terraform: More wiring in of new provider types
This doesn't actually work yet, but it builds and then panics in a pretty
satisfying way.
2018-10-16 19:12:54 -07:00
James Bardin c39e9e107f add Close methods to the plugin interfaces
Close was previously an optional interface, because it's only applicable
on the client side but the types were shared accross all packages. Since
all plugins will now implement Close, it no longer needs to be optional.
2018-10-16 19:11:09 -07:00
Martin Atkins a3403f2766 terraform: Ugly huge change to weave in new State and Plan types
Due to how often the state and plan types are referenced throughout
Terraform, there isn't a great way to switch them out gradually. As a
consequence, this huge commit gets us from the old world to a _compilable_
new world, but still has a large number of known test failures due to
key functionality being stubbed out.

The stubs here are for anything that interacts with providers, since we
now need to do the follow-up work to similarly replace the old
terraform.ResourceProvider interface with its replacement in the new
"providers" package. That work, along with work to fix the remaining
failing tests, will follow in subsequent commits.

The aim here was to replace all references to terraform.State and its
downstream types with states.State, terraform.Plan with plans.Plan,
state.State with statemgr.State, and switch to the new implementations of
the state and plan file formats. However, due to the number of times those
types are used, this also ended up affecting numerous other parts of core
such as terraform.Hook, the backend.Backend interface, and most of the CLI
commands.

Just as with 5861dbf3fc49b19587a31816eb06f511ab861bb4 before, I apologize
in advance to the person who inevitably just found this huge commit while
spelunking through the commit history.
2018-10-16 19:11:09 -07:00
James Bardin f9fee83279 minor providers.Interface fixes
Add a missing TerraformVersion field, and fix a TypeName field.
2018-10-16 18:58:49 -07:00
James Bardin 4fedf6c6f4 removing connection data from the providers
Very few resources need connection info, and rather than relying on
providers to set default for some resources, we are going to require
that connection blocks be explicitly set in the configuration.
2018-10-16 18:53:51 -07:00
James Bardin cd53b333f2 add config value to ApplyResourceChange
Providers will also need the config for reference during apply, in case
some of the config values were still unknown during plan.
2018-10-16 18:53:51 -07:00
James Bardin f77dd12e5c add Config to the PlanResourceChangeRequest
In order for providers to determine if a computed value was unset in the
configuration, the configuration must be passed along with the prior and
proposed states. Terraform core will still handle the creation of the
ProposedNewState to ensure correctness, but the raw configuration value
will also be supplied for comparison.
2018-10-16 18:53:51 -07:00
Martin Atkins 479c6b2466 move "configschema" from "config" to "configs"
The "config" package is no longer used and will be removed as part
of the 0.12 release cleanup. Since configschema is part of the
"new world" of configuration modelling, it makes more sense for
it to live as a subdirectory of the newer "configs" package.
2018-10-16 18:50:29 -07:00
James Bardin 12521366e1 Add ImportedResource type
The ImportResourceStateResponse command can return mutliple types.
ImportedResource maps the state to the appropriate type name, and also
allows providers to return Private data for each resource.
2018-10-16 18:50:29 -07:00
James Bardin dc78269a3c use cty.Value for connection info
For now this will be an encoded map, but it allows for a more complex
schema in the future.
2018-10-16 18:50:29 -07:00
James Bardin 960553e18b rename UpgradedState 2018-10-16 18:50:29 -07:00
James Bardin 6a1b57a1e4 split PriorStateRaw into JSON and Flatmap
This way the provider doesn't need to be concerned with determining the
state encoding.
2018-10-16 18:50:29 -07:00
James Bardin 91b5bbbde0 add versions to the provider schemas
We need to know the schema version for all resources. This is stored in
order to allow providers to upgrade the state from a known previous
version.
2018-10-16 18:50:29 -07:00
James Bardin 1473d09c50 rename provider and provisioner packages
Using plural names to avoid collisions in existing code.
2018-10-16 18:50:29 -07:00