Relationships
#3584 kubernetes/secret: idempotent ensure method and a metadata-only get
Opened by randybias · 10/17/2026· Shipped 10/19/2026
Problem
Two gaps in @swamp/kubernetes/secret (checked against 2026.10.13.1, models/secret.ts):
- No idempotent ensure.
createcallscreateNamespacedSecretand fails if the Secret exists.updatedoes read-then-replace and fails if it does not. A workflow that should converge a Secret to a desired state has to branch on existence itself, and a re-run after a partial failure breaks oncreate. - No way to read one Secret without its values.
getdecodes every value and writes it into thesecretresource.createandupdatealso write the decoded values back into stored data. The field is marked sensitive, so it is vaulted, but a caller that only needs to know "does it exist, which keys, what type, which resourceVersion" still copies the secret material into swamp's datastore.listreturns metadata only, but for the whole namespace.
Why it matters
Converging Secrets from a vault is a common GitOps-style job, and it should be safe to re-run. Keeping secret values out of model output by default limits where they can leak: vault backends, data exports, reports, logs and other tooling that reads model data.
Proposed solution
- An
ensure(orapply) method: read the Secret; create it if absent; if present, compare the desireddata/type/labelswith the current ones and replace (or server-side apply) only when they differ. Returnaction: created | updated | unchanged. An optionalprune: truewould drop keys not in the desired set; without it, keys are merged asupdatedoes today. Use the read'sresourceVersionon replace so concurrent writers get a 409, not a lost update. - A metadata-only read, either a
getMetamethod orgetwithincludeValues: false. It would write asecretMetaresource (name, namespace, type, dataKeys, labels, resourceVersion) and no values. Consider havingcreate/update/ensurewritesecretMetarather than decoded data too, since the caller already holds the values it sent.
Alternatives
Callers can try create, catch the 409 and fall back to update, and use list with a label selector to check one Secret's metadata. It works, but every workflow has to reimplement it, and create/update still persist the values.
Upstream repository: https://github.com/swamp-club/swamp-extensions
Environment
- Extension:
@swamp/kubernetes@2026.10.13.1 - swamp:
20261013.025835.0-sha.1b6f0c59 - OS:
linux(aarch64) - Deno:
2.9.7 - Shell:
/usr/bin/zsh
Shipped
Click a lifecycle step above to view its details.
system commented 10/17/2026, 5:08:51 PM
Classified automatically when this issue was filed.
- Source: Extensions
If you feel this classification is incorrect, add a ripple to tell us so.
stack72 commented 10/19/2026, 11:46:27 PM
Thanks @randybias for reporting this! We shipped: Add an idempotent ensure method and a metadata-only getMeta method to @swamp/kubernetes/secret. Both write only secretMeta, now with resourceVersion and, for ensure, a created/updated/unchanged action. Drift is compared in base64 form. Existing get/create/update output is unchanged. Also fix the adjacent namespace.ts 404 detection bug (statusCode vs ApiException code) that breaks the create path of setResourceQuota and setLimitRange, via a shared isNotFound helper.. The fix has been merged and a release is on its way. We appreciate your contribution to swamp.
Sign in to post a ripple.