Skip to content

bundle/direct: record resource operations with DMS#5387

Draft
shreyas-goenka wants to merge 1 commit into
mainfrom
shreyas-goenka/dms-version
Draft

bundle/direct: record resource operations with DMS#5387
shreyas-goenka wants to merge 1 commit into
mainfrom
shreyas-goenka/dms-version

Conversation

@shreyas-goenka
Copy link
Copy Markdown
Contributor

@shreyas-goenka shreyas-goenka commented May 31, 2026

Summary

When experimental.record_deployment_history is set, each successfully applied resource operation in the direct engine is reported to the deployment metadata service (DMS) via CreateOperation, in addition to the local state file. This is the first consumer of the record_deployment_history flag.

What changed

bundle/direct/oprecorder.goopRecorder interface + sdkRecorder:

type opRecorder interface {
	record(ctx context.Context, resourceKey string, action deployplan.ActionType, resourceID string, state any) error
}
  • Maps a deployplan action to its SDK OperationActionType. Non-mutating actions (Skip/Undefined) are rejected with an error rather than silently coerced.
  • The serialized config is carried in Operation.State so DMS can serve it as resource state; it is omitted for deletes (per the SDK contract).
  • Posts under the deployment version: deployments/{deployment_id}/versions/{version}.

bundle/direct/pkg.goDeploymentBundle.OpRec opRecorder, nil unless recording is enabled.

bundle/direct/bundle_apply.go — records after each successful create/update/recreate/resize/update_id/delete. Delete reads the resource ID before Destroy removes it from state. Migration mode records nothing.

bundle/phases/deploy.go — constructs the recorder in deployCore when b.Config.Experimental.RecordDeploymentHistory.

Design notes

  • Failure semantics: a failed CreateOperation fails the deploy, matching how local SaveState failures are treated — a state-backend write must not be silently lost.
  • Deployment version identity: the deployment ID and version come from the CreateVersion flow, which lands separately. Until then they are placeholders; record_deployment_history is experimental and off by default.

Test plan

  • go test ./bundle/direct/... ./bundle/phases/... green
  • go vet + ./task lint-q clean
  • CI

@shreyas-goenka shreyas-goenka changed the title bundle/direct: record resource operations when DMS is enabled bundle/direct: call DMS CreateOperation API on each resource operation May 31, 2026
@eng-dev-ecosystem-bot
Copy link
Copy Markdown
Collaborator

eng-dev-ecosystem-bot commented May 31, 2026

Commit: 2f36b2d

Run: 26727737026

@shreyas-goenka shreyas-goenka force-pushed the shreyas-goenka/dms-version branch from 2fb2f59 to 2f36b2d Compare May 31, 2026 23:34
@shreyas-goenka shreyas-goenka changed the title bundle/direct: call DMS CreateOperation API on each resource operation bundle/direct: record resource operations with DMS May 31, 2026
@shreyas-goenka shreyas-goenka changed the base branch from shreyas-goenka/bundle-lock-abstraction to shreyas-goenka/cli-managed-state-flag May 31, 2026 23:34
@shreyas-goenka shreyas-goenka force-pushed the shreyas-goenka/dms-version branch from 2f36b2d to d5f35f3 Compare June 1, 2026 15:28
@shreyas-goenka shreyas-goenka changed the base branch from shreyas-goenka/cli-managed-state-flag to main June 1, 2026 15:28
When experimental.record_deployment_history is set, each successfully
applied resource operation is reported to the deployment metadata service
(DMS) via the CreateOperation API, in addition to the local state file.

- opRecorder interface + sdkRecorder: record(action, id, state) maps a
  deployplan action to its SDK operation type and posts it under the
  deployment version. The serialized config is carried in Operation.State
  so DMS can serve it as resource state; it is omitted for deletes.
- deployActionToSDK rejects non-mutating actions (Skip/Undefined) rather
  than coercing them, so an unmapped action surfaces as an error.
- DeploymentBundle.OpRec is nil unless recording is enabled; the apply
  loop records after each create/update/recreate/resize/update_id/delete.
- A failed recording fails the deploy, matching how local state writes
  (SaveState) are treated: a state-backend write must not be silently lost.

The deployment ID and version that identify the DMS version are sourced
from the CreateVersion flow, which lands separately; until then they are
placeholders (record_deployment_history is experimental and off by default).

Co-authored-by: Shreyas Goenka <shreyas.goenka@databricks.com>
@shreyas-goenka shreyas-goenka force-pushed the shreyas-goenka/dms-version branch from d5f35f3 to 465bc4a Compare June 1, 2026 15:31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants