terraform

Commit Graph

Author	SHA1	Message	Date
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	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	97db4b8b12	rpcapi: Opening and closing dependency lock objects Currently we only support "opening" a dependency lock object by reading from an existing dependency lock file. In future we might also support mutating dependency lock objects in which case we'd probably also want a "create an empty dependency locks" operation, but we'll wait and see whether we even need that before over-complicating things here.	2 years ago
Martin Atkins	9bd6489dda	rpcapi: Stacks.FindStackConfigurationComponents This function returns a summary of the components and embedded stacks declared inside a given stack configuration. This reports only on static information that doesn't require any dynamic evaluation or provider plugin execution, so it should be sufficient to build a skeleton of the UI representing the content of a configuration that can then be populated with dynamic information in later steps, to make the UI feel responsive.	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

5 Commits (5848d8a2b4e0c500c384bcbdcc84b5feec3f6549)