11 Commits (5848d8a2b4e0c500c384bcbdcc84b5feec3f6549)

Author	SHA1	Message	Date
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