We don't use this library anywhere else in Terraform, and this backend was
using it only for trivial helpers that are easy to express inline anyway.
The new direct code is also type-checkable, whereas these helper functions
seem to be written using reflection.
This gives us one fewer dependency to worry about and makes the test code
for this backend follow a similar assertions style as the rest of this
codebase.
This also transitively upgrades golang.org/x/sys and golang.org/x/net,
but there do not seem to be any significant changes compared to the
commits we were previously using.
CVE-2020-26160 is a high-severity advisory reported against this module.
The dgrijalva package is no longer maintained but our legacy etcv2 backend
depends on it indirectly, via go.etcd.io/etcd/client. The golang-jwt
package is the blessed successor of the original, and has a v3 line which
is compatible with the v3 line of dgrijalva, and so through this replace
we can get a fix for the advisory without other significant behavior
change.
We've preserved the etcdv2 backend as-is on a best-effort basis in order
to support anyone who is already using it, but recommend that users switch
to etcdv3 or to some other backend for ongoing use.
We also have future plans to make state storage be a matter for provider
plugins rather than built in to Terraform CLI, at which point this backend
will either become obsolete or be factored out into its own plugin, at
which point we can remove this "replace" directive and the associated
dependency altogether.
For now, only check the JSON views package, since this was the instance
that most recently tripped us up. There are a few dozen failures
elsewhere in Terraform which would need to be addressed before expanding
this to other packages.
We have a few different .proto files in this repository that all need to
get recompiled into .pb.go files each time we change them, but we were
previously handling that with some scripts that just assumed that protoc
and the relevant plugins were already installed on the system somewhere,
at the right versions.
In practice we've been constantly flopping between different versions of
these tools due to folks having different versions installed in their
development environments. In particular, the state of the .pb.go files
in the prior commit wasn't reproducible by any single version of the tools
because they've all slightly diverged from one another.
In the interests of being more consistent here and avoiding accidental
inconsistencies, we'll now centralize the protocol buffer compile steps
all into a single tool that knows how to fetch and install the expected
versions of the various tools we need and then run those tools with the
right options to get a stable result.
If we want to upgrade to either a newer protoc or a newer protoc-gen-go
in future then we'll do that in a central location and update all of the
.pb.go files at the same time, so that we're always consistently tracking
the same version of protocol buffers everywhere.
While doing this I attempted to keep as close as possible to the toolchain
we'd most recently used, but since they were not consistent with each
other they've now all changed which version numbers they record at minimum,
and the planproto stub in particular now also has a slightly different
descriptor serialization but is otherwise offering the same API.
TencentCloud deleted all their v3 tags, so any system that does not use
the global Go proxy will fail to find the
github.com/tencentcloud/tencentcloud-sdk-go module source.
Update go.mod to point to the specific commit rather than the
incompatible and missing version tag.
Go 1.17 has a new treatment of go.mod where it tracks more indirect
dependencies in return for needing to fetch and load fewer transitive
go.mod files.
This commit opts in to that new treatment and adds all of the additional
indirect dependencies which contain packages that Terraform directly or
indirectly makes use of.
There are more details on what's going on here in the "Lazy Module Loading"
design document:
http://golang.org/design/36460-lazy-module-loading
(the design document was written assuming this would land in Go 1.15, but
it actually landed in Go 1.17 and so it's "go 1.17" that selects the new
behavior in spite of the examples in that document.)
etcd rewrote its import path from coreos/etcd to go.etcd.io/etcd.
Changed the imports path in this commit, which also updates the code
version.
This lets us remove the github.com/ugorji/go/codec dependency, which
was pinned to a fairly old version. The net change is a loss of 30,000
lines of code in the vendor directory. (I first noticed this problem
because the outdated go/codec dependency was causing a dependency
failure when I tried to put Terraform and another project in the same
vendor directory.)
Note the version shows up funkily in go.mod, but I verified
visually it's the same commit as the "release-3.4" tag in
github.com/coreos/etcd. The etcd team plans to fix the release version
tagging in v3.5, which should be released soon.
Some users would want to use Consul namespaces when using the Consul
backend but the version of the Consul API client we use is too old and
don't support them. In preparation for this change this patch just update
it the client and replace testutil.NewTestServerConfig() by
testutil.NewTestServerConfigT() in the tests.
* lang/funcs: add (console-only) TypeFunction
The type() function, which is only available for terraform console,
prints out the type of a given value. This is mainly intended for
debugging - it's nice to be able to print out terraform's understanding
of a complex variable.
This introduces a new field for Scope: ConsoleMode. When ConsoleMode is true, any additional functions intended for use in the console (only) may be added.
This includes the improvements to various collection-related functions to
make them handle marks more precisely. For Terraform in particular that
translates into handling sensitivity more precisely, so that non-sensitive
collections that happen to contain sensitive elements won't get simplified
into wholly-sensitive collections when using these functions.
Although we don't typically do configuration-level string wrangling
directly in Terraform, we delegate to several other upstream libraries
that do. These upgrades all switch to newer versions that support the
latest definitions from Unicode 13, primarily affecting operations such
as converting strings to upper/lowercase or splitting strings into
component characters (substr, reverse, etc).
The tests for the upstream libraries didn't show any regressions from
these updates, so the Unicode 13 changes seem to be backward-compatible
additions rather than significant breaking changes.
(Our go.mod file had also become non-canonical in some ways, and the Go
toolchain fixed that as part of this work, causing a few extra style-only
diffs here that shouldn't cause any change in behavior.)
This is just a prototype to gather some feedback in our ongoing research
on integration testing of Terraform modules. The hope is that by having a
command integrated into Terraform itself it'll be easier for interested
module authors to give it a try, and also easier for us to iterate quickly
based on feedback without having to coordinate across multiple codebases.
Everything about this is subject to change even in future patch releases.
Since it's a CLI command rather than a configuration language feature it's
not using the language experiments mechanism, but generates a warning
similar to the one language experiments generate in order to be clear that
backward compatibility is not guaranteed.
As part of ongoing research into Terraform testing we'd like to use an
experimental feature to validate our current understanding that expressing
tests as part of the Terraform language, as opposed to in some other
language run alongside, is a good and viable way to write practical
module integration tests.
This initial experimental incarnation of that idea is implemented as a
provider, just because that's an easier extension point for research
purposes than a first-class language feature would be. Whether this would
ultimately emerge as a provider similar to this or as custom language
constructs will be a matter for future research, if this first
experiment confirms that tests written in the Terraform language are the
best direction to take.
The previous incarnation of this experiment was an externally-developed
provider apparentlymart/testing, listed on the Terraform Registry. That
helped with showing that there are some useful tests that we can write
in the Terraform language, but integrating such a provider into Terraform
will allow us to make use of it in the also-experimental "terraform test"
command, which will follow in subsequent commits, to see how this might
fit into a development workflow.
Martin Atkins