Proto commits in pulumi/pulumi-kubernetes-operator

These 14 commits are when the Protocol Buffers files have changed:

2025-02-08

feat: report status when stack is locked (#807) ### Proposed changes - **Surfaces Locked Stack Errors:** - The agent server now returns a structured response instead of an error when the Pulumi CLI returns a `409` (Conflict) error. - Clients can now determine if a stack is locked without parsing error streams. - Introduced a new boolean response field, `isStackLocked`, for easy client-side detection. - **Improves Stack CR Status Updates:** - The error message from `UpdateCR.status.message` is now correctly propagated to `StackCR.status.lastUpdate.message`. - Ensures locked stack errors are surfaced in the Stack CR's status subresource. #### Example Stack CR Status Block ``` status: conditions: - lastTransitionTime: "2025-02-06T00:11:09Z" message: reconciliation is in progress reason: NotReadyInProgress status: "False" type: Ready - lastTransitionTime: "2025-02-06T00:11:09Z" message: 4 update failure(s) reason: RetryingAfterFailure status: "True" type: Reconciling lastUpdate: failures: 4 generation: 4 lastAttemptedCommit: sha256:f335a9e0bc445b0dbe3187371f56017bcdd66e23b68c6eda54910eeb48d5e3a0 lastResyncTime: "2025-02-06T00:26:33Z" lastSuccessfulCommit: sha256:f335a9e0bc445b0dbe3187371f56017bcdd66e23b68c6eda54910eeb48d5e3a0 message: Another update is currently in progress name: nginx-stack-194d8a6b139 state: failed type: up observedGeneration: 4 outputs: availableReplicas: 1 ``` #### Example Update CR Status Block ``` status: conditions: - lastTransitionTime: "2025-02-06T00:26:33Z" message: "" observedGeneration: 1 reason: Complete status: "False" type: Progressing - lastTransitionTime: "2025-02-06T00:26:33Z" message: Another update is currently in progress observedGeneration: 1 reason: StackLocked status: "True" type: Failed - lastTransitionTime: "2025-02-06T00:26:33Z" message: "" observedGeneration: 1 reason: Updated status: "True" type: Complete endTime: "1970-01-01T00:00:00Z" message: Another update is currently in progress observedGeneration: 1 startTime: "1970-01-01T00:00:00Z" ``` ### Testing - Added envtests to validate that statuses are correctly surfaced. - Manually validated on a GKE cluster. ### Related Issues Fixes: #806 Fixes: #736

The documentation is generated from this commit.

2024-10-17

[v2] Set config all at once (#718) We currently issue one `SetAllConfig` RPC for each user-specified config. This is slow but it has important correctness guarantees: 1. The order we apply config matters -- if the user specifies `foo: foo` followed by `foo: bar`, the net result must always be `foo: bar`. 2. The Pulumi CLI (and therefore Automation API) only allows specifying `--path` on an all-or-nothing basis. This is bad for us because we potentially have a blend of path and non-path keys. Ideally we would be able to supply all of our configs to the automation API in a single call, and in the case where _all_ of our config keys are path-like (or all are not path-like) we actually can do that because we no longer have limitation (2). This PR makes that possible in the general case by transforming our config keys in a way that allows us to treat them as if they are all path-like. In particular: * The agent's `SetAllConfig` handler is modified to take a list of configs instead of a map in order to preserve config order. The top-level `path` param is also removed and handled on a per-key basis. * While resolving configs, we escape any non-path keys so subsequent path parsing treats them as verbatim. For example `foo.bar` gets escaped as `["foo.bar"]`. * We can then supply all of our keys at once to Automation API with `Path: true`. * If there are no configs to set then the operator doesn't invoke `SetAllConfig`. Fixes https://github.com/pulumi/pulumi-kubernetes-operator/issues/650

2024-09-26

[v2] Consolidate go.mod (#686) * Consolidate `{operator,agent}/go.mod` under a root `go.mod`. * Rewrite imports to use v2 path. * Remove `/test` -- these were still referring to v1 code and can be revived in a followup if we want to keep any of them. * Move Dockerfile to repo root and fix image build. Fixes https://github.com/pulumi/pulumi-kubernetes-operator/issues/687. --------- Co-authored-by: Eron Wright <eron@pulumi.com>

2024-09-25

[v2] Capture stack outputs (#676) This returns stack outputs from the agent and records them in a secret. Scrubbed outputs are also stored in the Stack's status, as we do in v1. * `OutputValue` is returned from the agent and contains raw JSON-encoded bytes for the output. * Each `Update` owns a corresponding `-stack-outputs` secret. * The secret includes a `pulumi.com/secrets` annotation with a list of sensitive fields, and the Stack API uses this to scrub outputs for the Stack's status.

2024-08-08

[pkov2] agent RPC server (#624) <!--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**: https://github.com/pulumi/pulumi-kubernetes-operator/issues/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 https://github.com/pulumi/pulumi/pull/16782. Note that PKOv1 has some code to install plugins, now believed to be obsolete (see [discussion](https://github.com/pulumi/pulumi/pull/16782#issuecomment-2259286745)). 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

2024-08-02

SetAllConfig

SelectStack

2024-08-01

installation support

2024-07-31

zap logging

2024-07-26

init containers

2024-07-21

preview event stream

preview, cancelation

2024-07-15

deployable

2024-07-12

proto 1