Develop the grpc proto specification #610
Assignees
Milestone
Comments
|
Added to epic #586 |
5 tasks
EronWright
added a commit
that referenced
this issue
Aug 8, 2024
<!--Thanks for your contribution. See [CONTRIBUTING](CONTRIBUTING.md)
for Pulumi's contribution guidelines.
Help us merge your changes more quickly by adding more details such
as labels, milestones, and reviewers.-->
### Proposed changes
**Epic Link**:
#606
**Demo Video Link**:
https://pulumi.slack.com/archives/C07DQSV84DC/p1722636430008649
Implements an agent consisting of two commands:
- `init` - fetches a flux source into the given directory, intended for
use in an init container.
- `serve` - starts an RPC server providing an automation API to perform
stack updates over the given workspace.
### Overview
The RPC server assumes that the project source code has been checked out
to a local working directory, called the "workspace" directory. This
generally corresponds to a sub-directory within a git repository, e.g.
[examples/random-yaml](https://github.com/pulumi/examples/tree/master/random-yaml).
At startup, the server opens the workspace using
[auto.NewLocalWorkspace](https://github.com/pulumi/pulumi/blob/5651750bb254f73da5ef0fa503818c5a38755ea8/sdk/go/auto/local_workspace.go#L848).
All RPC operations are applied to this same workspace, usually
one-at-a-time. Some operations cause state changes, e.g. stack
selection, that may affect subsequent operations. Some operations
produce `PreconditionFailed` if a stack hasn't been selected.
At startup, the server optionally runs `pulumi install` to install
dependencies and plugins for the project, based on
pulumi/pulumi#16782. Note that PKOv1 has some
code to install plugins, now believed to be obsolete (see
[discussion](pulumi/pulumi#16782 (comment))).
The supported operations are:
- `WhoAmI` - returns current user info.
- `Install` - runs `pulumi install` in the workspace.
- `SelectStack` - select (and optionally create) a stack, for use in
subsequent operations.
- `Info` - a summary of the current stack.
- `SetAllConfig` - set multiple configuration values on the current
stack, based on literals, environment variables, and file references. It
is expected that the server's pod would have ConfigMaps and Secrets
mounted accordingly.
- `Preview` runs the preview operation for the current stack.
- `Up` runs the up operation for the current stack.
- `Destroy` runs the destroy operation for the current stack.
- `Refresh` runs the refresh operation for the current stack.
The deployment operations have streaming responses, consisting of a
series of engine events and a final result.
The agent uses zap for logging, because it supports structured logging,
implements `io.Writer` to capture Pulumi console output, and integrates
well with grpc-go.
### Follow-ups
- [x] Write RPC server tests
- [ ] Rename 'init' to 'fetch' for clarity
- [ ] lock the workspace during an operation? Or rely on locking within
the Pulumi CLI?
### Related issues (optional)
<!--Refer to related PRs or issues: #1234, or 'Fixes #1234' or 'Closes
#1234'.
Or link to full URLs to issues or pull requests in other GitHub
repositories. -->
Closes #610 #611
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Finalize the subset of auto API methods to be exposed via gRPC, based on the needs of the PKO project.
WhoAmIInfoRefreshPreviewUpDestroyIf stack selection happens implicitly during the operation, there's probably no need for any explicit stack management commands.
Use streaming responses as appropriate, e.g. for deployment operations where an event stream is available.
The text was updated successfully, but these errors were encountered: