[pkov2] agent RPC server #624
Conversation
EronWright
added
the
impact/no-changelog-required
| @@ -0,0 +1,54 @@ | |||
| # Build the agent binary | |||
| FROM golang:1.22 AS builder | |||
There was a problem hiding this comment.
| FROM golang:1.22 AS builder | |
| FROM --platform=$BUILDPLATFORM golang:1.22 AS builder |
This will build in a native image instead of an emulated one when cross-compiling.
| @@ -0,0 +1,114 @@ | |||
| module github.com/pulumi/pulumi-kubernetes-operator/agent | |||
There was a problem hiding this comment.
Structure nits:
- We should put the new code under a v2 subdirectory.
- We should try as hard as possible to keep one
go.modat the root of the repo, unless there's a legitimate version incompatibility that's non-trivial to resolve between v1 and v2. (Is there?) - If we absolutely need a new module, it should be under v2 so the agent and server both belong to it since they're versioned together.
Unnecessary modules are a big source of accidental complexity and lead to all sorts of headaches and gotchas down the line (example). Trust me on this one :)
There was a problem hiding this comment.
I plan to tackle the larger structural stuff in a follow-up.
| optional bool path = | ||
| 1; // Parse the keys as paths in a map or list rather than raw strings |
There was a problem hiding this comment.
Am I right in thinking this basically resolves the structure config problem by letting you mount any config map you want into the pod and use that as your stack config directly? Does that mean SetAllConfig would only get invoked once per operation?
There was a problem hiding this comment.
This SetAllConfig RPC method closely mirrors the underlying auto api, that takes a path bool to indicate that the keys in the provided map are "paths" as opposed to literal config keys. What's special here is that the RPC method is able to resolve "valueFrom" refs that draw values from environment variables and local files.
The Stack controller calls SetAllConfig today after extracting values from configmaps and secrets. In the v2 design, the controller doesn't see the values. The configmaps/secrets are mounted onto the workspace pod (as envs and/or files) and then read via these "valueFrom" refs.
I'm not seeking to solve structured config beyond what auto api can do today.
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## v2 #624 +/- ##
=========================================
+ Coverage 8.76% 17.14% +8.37%
=========================================
Files 4 8 +4
Lines 1164 1960 +796
=========================================
+ Hits 102 336 +234
- Misses 1055 1543 +488
- Partials 7 81 +74 ☔ View full report in Codecov by Sentry. |
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.
At startup, the server opens the workspace using auto.NewLocalWorkspace. 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
PreconditionFailedif a stack hasn't been selected.At startup, the server optionally runs
pulumi installto 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).The supported operations are:
WhoAmI- returns current user info.Install- runspulumi installin 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.Previewruns the preview operation for the current stack.Upruns the up operation for the current stack.Destroyruns the destroy operation for the current stack.Refreshruns 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.Writerto capture Pulumi console output, and integrates well with grpc-go.Follow-ups
Related issues (optional)
Closes #610 #611