* Update protoc version in downloader script
* go get google.golang.org/grpc/cmd/protoc-gen-go-grpc v1.5.1
This matched terraform-plugin-go
* make protobuf
* Run `make protobuf`
* Update generator to handle generic types from google.golang.org/grpc
Looks like this was added in v1.69.3 in https://github.com/grpc/grpc-go/pull/7057 ?
* Run `make generate`
* Fix "cannot infer Res" compile error - more usage of generics
* More fixing compile errors due to switching to use of a generic
* Make putting `google.golang.org/grpc` import into generated files conditional
* Run `make generate`
* Update more places where generics now need to be used
* Update generator to handle any types from google.golang.org/grpc in same switch case.
* Remove `require_unimplemented_servers=false` option when generating code from proto files. Run `make protobuf`.
This allows require_unimplemented_servers to default to true, and the generated code shows the impacts of that.
* Update generator script to embed 'UnimplementedFoobarServer' structs and skip generating code for the `mustEmbedUnimplementedFoobarServer` method that is implemented via that embedding.
* Run `make generate`
* Embed UnimplementedProviderServer into implementations of ProviderServer
* Embed UnimplementedProvisionerServer into implementations of ProvisionerServer
* Reformat Args in steps definitions
* Swap to using the new version of protoc-gen-go that doesn't include grpc support (instead it relies on protoc-gen-go-grpc).
Update command flags to reflect this change in tooling.
See this comment for explanation: https://github.com/golang/protobuf/issues/1070#issuecomment-607293496
* Run `make protobuf` with problem generate steps commented out.
* Use `require_unimplemented_servers=false` to minimise changes at the time of upgrading tooling
In future we can navigate the consequences of this in its own PR.
* WIP
* Fix out/opt typo, add remaining flags once terraform1.proto was being found ok
* Run `make protobuf`
* `go get google.golang.org/grpc/cmd/protoc-gen-go-grpc@v1.3.0` && `go mod tidy`
This version includes a feature that allows the copyright comment in the .proto file to be pulled across to generated _grpc.pb.go files.
* Run `make protobuf` with new version of protoc-gen-go-grpc that allows copyright comment to be copied to generated output files
* Potential fix for `internal/rpcapi/dynrpcserver/generator`
Previously we expected clients to provide an inline raw prior state to
PlanStackChanges and an inline raw plan to ApplyStackChanges, which was
a simpler design but meant that we might end up generating a state or plan
that's too large to be submitted in a single gRPC request, which would then
be difficult to resolve.
Instead we'll offer separate RPC functions for loading raw state and plan
using a gRPC streaming approach, which better mirrors the streaming
approach we use to _emit_ these artifacts. Although we don't actually need
this benefit right now, this makes it possible in principle for a client
that's running PlanStackChanges to feed back the raw planned actions
concurrently into OpenPlan and thus avoid buffering the whole plan on the
client side at all.
This required resolving the pre-existing FIXME about the inconsistency
where stackeval wants a raw plan for apply but expects the caller to
have dealt with loading the prior state for planning. Here it's resolved
in the direction of the caller (rpcapi) always being responsible for
loading both artifacts, because that means we can continue supporting the
old inline approach for a while without that complexity having to infect
the lower layers.
Ideally we should remove the legacy approach before this API becomes
constrained by compatibility promises, but I've preserved the old API
for now to give us some flexibility in when we update the existing
clients of this API to use the new approach.
Co-authored-by: Martin Atkins <mart@degeneration.co.uk>
This was unimplemented because we didn't end up needing it. We might find
a use for something like it someday, but we'll wait and see what the
requirements are before we properly define it as part of the API.
(The current way we achieve "finding providers" is to use a dependency
lock file which is assumed to already contain exact provider selections.
The most likely reason for something like FindStackConfigurationProviders
to return is to allow building a tool for generating those dependency
lock files, which will require analyzing the configuration to find which
providers it actually depends on, but it remains to be seen exactly what
API would make sense for that operation.)
Here we introduce a new evaluation phase for the stacks runtime called
"inspect", which aims to provide a read-only view of a configuration and
an associated state snapshot.
The main idea of this is to use it as a more convenient vehicle for unit
testing despite it not really being viable to decompose the main
evaluation logic into smaller parts: the language features are all directly
interdependent on one another, but we can at least minimize our
interactions with the Terraform modules runtime when we're testing
anything other than actually planning and applying components.
However, this also gives an opportunity to expose evaluation of arbitrary
expressions in a similar manner as "terraform console", which is for now
just another debugging aid but will probably someday appear as a
Stacks-flavored version of the "terraform console" command.
This new operation allows opening a dependency locks handle with lock
information provided inside the request, rather than creating one
indirectly from a dependency lock file.
This is intended to allow a caller to start with a dependency lock file,
saved the locked providers somewhere, and then in a later step using a
different Terraform Core RPC server instantiate another locks object with
the same providers without requiring access to the original dependency
lock file.
In future we might add a function for writing locks to disk as a dependency
lock file, which would then allow callers to construct entirely new
dependency lock files by providing the intended content themselves. We
don't have any direct need for that now, but that would complete this
family of functions if we added it later.
This also includes a small additional RPC function GetBuiltInProviders to
fill the small gap resulting from the fact that built-in providers never
appear in a plugin cache directory, and therefore previously there was no
way to discover which built-in providers are available to complement the
set of plugin-based providers.
Our generator for the wrapper stubs for the dynamically-instantiated gRPC
services could not previously handle the slightly different signature used
for the methods generated for RPC functions that return streaming
responses: they take a stream object as an argument instead of returning
a message directly.
Now we can generate wrapper stubs for those methods too, so that
subsequent commits can include the real implementations of those functions.
This commit includes just an unimplemented husk of Stacks.PlanStackChanges
as a placeholder to demonstrate that it's working.
Previously we were trying to add new services to the gRPC server after it
was already running, which worked okay in the contrived fake setup I was
using to test it in isolation but is rejected by the real gRPC server
implementation, which requires all service registration to happen prior
to starting the server.
Instead then, we'll use some wrapper server implementations that initially
just return "Unavailable" errors for every request but can then be tardily
initialized with a real server implementation that takes over serving
requests once registered.
This involves some gnarly code generation for the wrapper server
implementations because this situation is beyond the current capabilities
of Go generics. The code generator implementation is pretty gross but this
approach was the least horrible of various other things I tried in order
to avoid writing a code generator.
The code generator may need some additional work later once we introduce
our first streaming RPC function, but after that it should hopefully
remain unchanged for a long time as long as we stick to the current API
design idiom for future services.
