terraform

Commit Graph

Author	SHA1	Message	Date
Radek Simko	cee1246acc	rpcapi: Manually update copyright in template	2 months ago
Radek Simko	0fe906fa8c	make copyrightfix	2 months ago
Sarah French	2e5b5dee5d	Upgrade protoc and protoc-gen-go-grpc versions to matching terraform-plugin-go (#37647 ) * 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.	6 months ago
Sarah French	2657a4daec	Set let require_unimplemented_servers default to true when generating code from .proto files (#37737 ) * 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	6 months ago
Sarah French	ffbb62b369	Swap to using `google.golang.org/protobuf/cmd/protoc-gen-go` instead of `github.com/golang/protobuf/protoc-gen-go` (#37685 ) * 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`	7 months ago
Samsondeen	71dbc7d726	migrate command for terraform stacks (#36482 )	1 year ago
Daniel Schmidt	43fe6ca8cc	stacks: add rpc call to list resource identities of a stack	1 year ago
Liam Cervante	915b174da3	stacks: split the terraform1 RPC package into per-service packages (#35513 ) * stacks: split the terraform1 RPC package into per-service packages * pull latest changes	2 years ago
Alisdair McDiarmid	d828776757	stacks+rpcapi: Load prior state and plan separately 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>	2 years ago
Radek Simko	30aa3cb743	rpcapi: Add missing license headers & code-generation headers (#34617 )	2 years ago
Liam Cervante	dee12de5e0	stacks: Add ValidateStackConfiguration RPC to stacks API service (#34347 )	2 years ago
Liam Cervante	e703eb7b17	stacks: add the packages service to the rpc api (#34319 ) * stacks: add the packages service to the rpc api * go generate	2 years ago
Martin Atkins	b54a5be8e9	rpcapi: Remove Stacks.FindStackConfigurationProviders function 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.)	2 years ago
Martin Atkins	9a943af56d	stackruntime: Arbitrary expression evaluation 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.	2 years ago
Martin Atkins	ac93c1bb82	rpcapi: Add HashiCorp copyright comments	2 years ago
Martin Atkins	701ab1480e	rpcapi: Stacks.ApplyStackChanges initial schema There is not yet any real implementation of this new function. The implementation will follow in future commits.	2 years ago
Martin Atkins	48add21996	rpcapi: Dependencies.CreateDependencyLocks 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.	2 years ago
Martin Atkins	96627b7282	rpcapi: Dependencies service provider schema export 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.	2 years ago
Martin Atkins	77e5b787d9	rpcapi: Dependencies: new API schema for provider dependency handling This does not include any implementation of this new API surface; that will follow in subsequent commits.	2 years ago
Martin Atkins	97ee2f14c3	rpcapi: codegen for RPC functions with streaming responses 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.	2 years ago
Martin Atkins	14759c1d04	rpcapi: A different approach to late server initialization 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.	2 years ago

21 Commits (add-missing-variable-loading)