10 Commits (148b19b0d7e36b6f2b8a169d2cb7b6069ab5d00a)

Author	SHA1	Message	Date
Martin Atkins	67d8a5137b	rpcapi+stacks: Stacks runtime can see whether experiments are allowed ... We allow experiments only in alpha builds, and so we propagate the flag for whether that's allowed in from "package main". We previously had that plumbed in only as far as the rpcapi startup. This plumbs the flag all the way into package stackeval so that we can in turn propagate it to Terraform's module config loader, which is ultimately the one responsible for ensuring that language experiments can be enabled only when the flag is set. Therefore it will now be possible to opt in to language experiments in modules that are used in stack components.	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	ac93c1bb82	rpcapi: Add HashiCorp copyright comments	2 years ago
Martin Atkins	10d665181a	rpcapi: NewInternalClient returns a socketless RPC client ... Right now we are only using rpcapi from external callers inside Terraform Cloud, but in the long run we will also want to expose equivalent functionality through Terraform CLI. rpcapi.NewInternalClient provides a relatively-lightweight way to achieve that without requiring a child process and sockets. Instead, it just allocates a buffer and passes gRPC messages between client and server using that buffer. This is of course still not as efficient as a direct function call, but the kinds of operations that RPC API exposes tend to have far more expensive elements than the RPC call itself, and using the RPC protocol as the internal API should begin to establish a more explicit architecture boundary between Terraform CLI and Terraform Core, so that clients of the RPC API have the same level of access to Terraform Core as the CLI workflow does. So far we don't have any internal callers for this because nothing in the RPC API has a corresponding CLI entry point. The first callers of this internal RPC interface will probably be the commands providing the CLI-driven development workflow for stacks.	2 years ago
Martin Atkins	7747865234	rpcapi: Dependencies service provider installation and cache mgmt ... This implements the rpcapi operations for building and manipulating provider plugin cache directories, which in later commits we'll be able to pass to some of the Stacks service operations so that the stacks runtime can work with non-builtin 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	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
Martin Atkins	72290e1f5c	rpcapi: Management of "handles" ... As with many other systems that involve a client indirectly manipulating objects on the other side of a trust boundary, we're going to use opaque "handles" to represent objects that remain active on the server side between different RPC API calls. A handle is just a 64-bit integer corresponding to an entry in a lookup table maintained by the server, in the "handleTable" type. In the public API we don't make any promises about uniqueness of handles between different types of objects, but to minimize the impact of client bugs we'll internally ensure that we never issue the same handle number for two objects of different types. This means that a client getting their handles mixed up will typically cause an explicit error rather than just doing something weird with an unrelated object that happened to have a matching handle. Our internal API for this will use explicit separate methods for each type of handle and use type parameters so that the Go compiler can call us out if we're inconsistent in how we're using the handles. From a client perspective though these all just layer to protobuf int64; clients might choose to add their own similar abstraction to track handle types, but that's their own business since we can't represent such things efficiently within the protocol buffers schema model. This commit includes initial implementations of Dependencies.OpenSourceBundle and Dependencies.CloseSourceBundle just as some initial evidence that this design works. We'll continue implementing the other real service functions in later commits once the basic infrastructure (like this) is in place.	2 years ago
Martin Atkins	3bf1a5cf53	rpcapi: Now wired up to the "terraform rpcapi" plumbing command ... This doesn't actually do anything useful yet, but this does at least make the RPC server accessible to external callers where they can handshake and then get an error saying that nothing else is implemented.	2 years ago
Martin Atkins	38d66ea74d	rpcapi: Initial stubbing of the plugin server setup	2 years ago