In study of existing providers we've found a pattern we werent previously
accounting for of using a nested block type to represent a group of
arguments that relate to a particular feature that is always enabled but
where it improves configuration readability to group all of its settings
together in a nested block.
The existing NestingSingle was not a good fit for this because it is
designed under the assumption that the presence or absence of the block
has some significance in enabling or disabling the relevant feature, and
so for these always-active cases we'd generate a misleading plan where
the settings for the feature appear totally absent, rather than showing
the default values that will be selected.
NestingGroup is, therefore, a slight variation of NestingSingle where
presence vs. absence of the block is not distinguishable (it's never null)
and instead its contents are treated as unset when the block is absent.
This then in turn causes any default values associated with the nested
arguments to be honored and displayed in the plan whenever the block is
not explicitly configured.
The current SDK cannot activate this mode, but that's okay because its
"legacy type system" opt-out flag allows it to force a block to be
processed in this way anyway. We're adding this now so that we can
introduce the feature in a future SDK without causing a breaking change
to the protocol, since the set of possible block nesting modes is not
extensible.
Nulls can't exist in HCL, and the legacy sdk will panic when
encountering them. The map shim already did this, just copy the same
pattern in the list case.
Add the (forces new resource) annotation to the diff output for provider
tests failures when we can. This helps providers narrow down what might
be triggering changes when encountering test failures with the new SDK.
The SDK uses only the native int and float64 types internally for values
that are specified as being "number" in schema, so for SDK purposes only
a float64 level of precision is significant.
To avoid any weirdness introduced as we shim and un-shim numbers, we'll
reduce floating point numbers to float64 precision before comparing them
to try to mimic the result the SDK itself would've gotten from comparing
its own float64 versions of these values using the Go "==" operator.
This is a first pass of an "approximately equal" function that tries to
mimic the reduced precision caused by the field reader abstraction in
helper/schema so that we can distinguish between meaningful changes to
the proposed new state and incidental ones that just result from the loss
of precision in the SDK implementation.
This reverts commit 3677522a28.
Later changes negate the need for this, and removing these again
prevents us from having to strip them back out when helper/schema
doesn't want them.
If a flatmap value has a count of 1 and no other attributes, it usually
indicates the equivalent configuration of an empty (or default value)
set block. Treat this as containing a single zero value object and
insert that into the set.
The flatmap shim was lazily adding duplicate items and letting cty.Set
clear them out, but if those duplicates contains unknown values they
can't be checked for equality and will end up remaining in the set.
This is a more specialized version of ConfigValueFromHCL2 which is
specifically for config values that represent the content of a block
body in the configuration.
By using the schema of that block we can more precisely emulate the old
HCL1/HIL behaviors by distinguishing attributes from blocks and applying
some slightly different behaviors for the handling of null values and
of empty collections that are representing the absense of blocks of a
particular type.
Make the function work specifically how we need for RequiresReplace.
Skip index changes, any set changes are only recorded as the set itself,
and filter out duplicate paths.
Add a few more tests to check for various nested structures.
Rather than try and make a generalized path function here, what we
really need in a function to generate the paths needed for
RequiresReplace. This needs to take into account that sets elements
don't need to be indexed themselves, and changes to collection index
values aren't needed.
PathFromFlatmapKey is used to convert a flatmap key to a cty.Path, and
ensures it conforms to the type schema.
This is used when handling Diffs, where the ResourceAttrDiffs are
indexed by the flatmapped key values, and we need to convert those to
addresses to apply to a cty.Value.
When creating a flatmap from a cty.Value, there may be Null collections
which don't need to be added to the flatmap at all. Skip over these to
avoid panicking in ElementIterator with a Null value.
A nil flatmap will be encoded as a NullVal of the correct type. When
Converting a NullVal back to a flatmap, return nil immediately rather
than attempting to build the values.
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.
Previously unknown values were round-tripping through flatmap and coming
out as known strings containing the UnknownVariableValue. (The classic bug
that, ironically, was one of the big reasons to write cty!)
Now we properly handle unknown values in both directions: going in to
flatmap we write UnknownVariableValue at the appropriate key (as the count
for sequences or maps) and then coming out of flatmap we turn
UnknownVariableValue back into a cty unknown value of the requested type.
These particular shims will have a pretty limited lifetime in mainline
Terraform code (primarily to stub out the new expression evaluator against
the old state structs until the new format is implemented) but will live
on for some time in state migration and provider plugin compatibility
shims.
This is a rather-messy, complex change to get the "command" package
building again against the new backend API that was updated for
the new configuration loader.
A lot of this is mechanical rewriting to the new API, but
meta_config.go and meta_backend.go in particular saw some major
changes to interface with the new loader APIs and to deal with
the change in order of steps in the backend API.
The usual way to use a configschema.Block is to obtain a hcldec spec from
it and then decode an hcl.Body. There are inevitably situations though
where a body has already been decoded into a cty.Value before we know
which schema we need to use.
This new method CoerceValue is intended to deal with this case, applying
the schema to an already-decoded value in what should be an intuitive way
for most situations.
We will need access to this information in order to render interactive
input prompts, and it will also be useful in returning schema information
to external tools such as text editors that have autocomplete-like
functionality.
Absent values are omitted by the old code we are emulating in HCL, so we
must do the same here in order to avoid breaking assumptions in the
helper/schema layer.
By adding this method you now only have to pass a `*disco.Disco` object around in order to do discovery and use any configured credentials for the discovered hosts.
Of course you can also still pass around both a `*disco.Disco` and a `auth.CredentialsSource` object if there is a need or a reason for that!
Previously we would return the raw error from strconv.ParseInt, which
includes details in its text that expose implementation details and are
thus not helpful to the user.
Instead, we use a locally-defined error message that talks only about
what the caller is expected to know: that count should be parsable as
an integer.
Previously our error message here was confusing and redundant:
Error starting operation: provider.null: invalid version constraint "not valid": Malformed constraint: not valid
Instead, we'll generate a full HCL2 diagnostic here, which results in
something (subjectively) nicer:
Error: Invalid provider version constraint
The value "@ 1.0.0" given for provider.null is not a valid version
constraint.
At the moment this message is an outlier in that the other validation
errors are all still just plain Go errors, but over time we'll want to
adjust all of these to be full diagnostics so that we can embed source
range information in them to help the user find the offending
configuration.
* Verify discovery works without trailing slash on discovery URL
* Update registry API docs with browse and search endpoints
* Add sample request/responses
* Add comment to test to indicate expecations
* Fix typo
* Remove trailing slash weirdness
Martin Atkins