Wire node-policy delete, replace-on-rename for rules, safe defaults, API resync and field alignment, CRUD test harness

[Tzvonimir]

What?

Brings the Pulumi provider back in line with the current DAKR API and fixes every critical found in the provider audit: pulumi destroy now actually deletes node policies and disables node-policy targets, renaming a workload rule replaces it instead of orphaning it, enabled defaults to true on targets as documented, out-of-band deletions drop from state instead of failing refresh, and string enums are validated instead of silently dropped. Protos are resynced to services HEAD, three deleted HPA fields are removed, the full set of new backend fields (v1 policies, v2 rules, targets, node policies) is exposed, and schema.json plus the Node/Python/Go SDKs are regenerated. Also removes a scratch file from the repo root that contained a live bearer token and gitignores the pattern.

Why?

The provider had drifted ~2 months behind the backend and had several bugs with real blast radius: destroy left Karpenter NodePools provisioning nodes, an omitted enabled silently created a disabled target while the docs said "default true", the retry interceptor could duplicate resources by retrying Creates, and hpaRule.targetUtilization/primaryMetric were silent no-ops (the backend deleted those fields in July). Terraform got the same treatment in devzero-inc/terraform-provider-devzero#28; this PR gives Pulumi users parity.

How?

• Breaking: hpaRule.targetUtilization, targetMemoryUtilization, primaryMetric are removed (already ignored server-side); hpaRule.metrics is the replacement. Cluster updates also no longer auto-rotate the token when state has none (post-import) — rotating on an unrelated rename silently invalidated the running agent's credential.
• WorkloadRule identity: the upsert API keys rules on (clusterId, namespace, kind, name), so Update on a renamed rule created a second rule while state kept the old ID. A CustomDiff now marks those four fields as replace-on-change.
• disabled on workload rules is create-only in the upsert API; updates route through the ToggleWorkloadRuleDisabled RPC.
• Node policy target destroy disables the target (no delete RPC exists); clusterIds validates to exactly one entry because the server rejects more.
• Strict enums (validation.go): the API silently ignores unknown enum strings (an unknown trigger is dropped, an unknown kind matches every workload), so Create/Update now fail fast with the valid-values list. Selector operators gain Gt/Lt.
• Retries only apply to Get*/List* RPCs — CreateNodePolicies without a client-set ID always inserts, so a retried Create duplicated resources.
• Refresh drift: float32 values read back via shortest-round-trip conversion (0.7 stays 0.7, not 0.699999988079071); omitted booleans no longer materialize as &false; HPA metric metadata strips the serverAddress/query keys the backend folds in.
• Node-policy reads skip the read-only source == "cluster" virtual policies ListNodePolicies mixes in.
• Makefile VERSION falls back to 0.0.0-dev (valid semver) — pulumi package get-schema rejected the old dev fallback, which broke gen-schema/gen-sdk in any clone without tags, including CI's fetch-depth: 1 checkout.

Testing?

• fake_server_test.go: an in-memory connect server (httptest + generated handlers) mimicking dakr semantics — upsert keys, NotFound codes, target invariants, fields.disabled rejection on update, virtual cluster policies — driving real Create/Read/Update/Delete lifecycles. Covers out-of-band deletion, delete idempotency, disable-on-destroy, the disabled-toggle path, exact float round-trips, and the enabled default.
• Existing unit tests updated to the new semantics (e.g. multi-cluster targets now assert rejection; NotFound reads assert drop-from-state; a new test asserts mutating RPCs are never retried and that updates never rotate tokens).
• go build ./..., go vet ./..., full suite green; the regenerated Go SDK compiles.

Anything Else?

The leaked bearer token that was in curl.txt should be rotated — deleting the file doesn't invalidate it. Deferred to a follow-up (same as the Terraform PR): gcp/oci node classes, kedaScaledObject, jvmHeapRule; plus release-workflow publish ordering and stale example version pins.

[gitar-bot]

Code Review ✅ Approved 3 resolved / 3 findings

Aligns the Pulumi provider with current API semantics, implementing real node-policy deletes, replace-on-rename for rules, safe target defaults, API resyncs, and a CRUD test harness. Addressed findings for NodePolicy.Read source filtering, retryInterceptor maxAttempts guards, and WorkloadRule.Kind validation.

✅ 3 resolved

✅ Edge Case: NodePolicy.Read blacklists source, may drop provider-managed policies

📄 provider/pkg/resources/node_policy.go:461-475
Read skips any policy whose Source is non-empty and not exactly "dakr". This is a blacklist keyed on one known bad value ("cluster"). If the backend ever tags API/IaC-created node policies with a different non-empty source string (e.g. "pulumi", "api"), Read would skip the managed policy, return an empty response, and the engine would drop it from state — causing a spurious re-create and a duplicate NodePool. Consider whitelisting the known-managed sources (empty and "dakr") explicitly and only skipping the specific virtual source(s) you intend to exclude (source == "cluster"), so an unexpected source value doesn't silently orphan a resource.

✅ Bug: retryInterceptor returns (nil,nil) if maxAttempts <= 0

📄 provider/pkg/provider/client.go:62-76
If maxAttempts is ever <= 0 the for loop body never executes and the interceptor falls through to return nil, nil, handing callers a nil response with a nil error, which will panic on the first field access. It is currently hardcoded to 3 at the call site so this is not reachable today, but the fallthrough is a latent trap. Guard maxAttempts (clamp to >= 1) or return an explicit error instead of nil,nil.

✅ Quality: WorkloadRule.Kind not validated against valid kinds

📄 provider/pkg/resources/validation.go:96-100 📄 provider/pkg/resources/workload_rule.go:255-262
validateWorkloadRuleArgs only validates actionTriggers and detectionTriggers; the Kind field (documented as one of Deployment/StatefulSet/DaemonSet/CronJob/Job) is passed straight through to UpsertManualWorkloadRule. Since the stated goal of the strict-enum work is to fail fast on unknown enum strings the API silently mishandles, and WorkloadPolicyTarget.kindFilter is validated against validKinds, consider validating WorkloadRule.Kind the same way so a typo'd kind fails with an actionable message rather than creating a rule the backend can't match.

_{Was this helpful? React with 👍 / 👎 | Gitar}