bundle/dstate: nullify local state when DMS recording enabled - #6541
Draft
shreyas-goenka wants to merge 1 commit into
Draft
bundle/dstate: nullify local state when DMS recording enabled#6541shreyas-goenka wants to merge 1 commit into
shreyas-goenka wants to merge 1 commit into
Conversation
When opening a deployment state with experimental.record_deployment_history enabled, the service is the source of truth for resources, not the local state file. Nullify the local state so it acts as a tombstone (carrying only the feature marker and header). This allows stale local state from a destroyed DMS deployment to bootstrap a fresh deployment, instead of erroring with "this deployment already exists and is not recorded". The fix removes the guard that previously prevented enabling DMS on deployments with local resources. This is a necessary tradeoff to support the common scenario where a DMS deployment is destroyed on the service but the local state cache remains. The service is now authoritative: - If dmsDeploymentID is non-empty: ListResources fetches the service's resources - If dmsDeploymentID is empty: no resources are loaded (fresh/destroyed deployment) Tradeoff: this also allows enabling DMS on an existing non-DMS deployment, which could leave old resources orphaned if they have different IDs or names. Users should destroy a non-DMS deployment before enabling DMS to avoid this scenario. Accept this tradeoff to unblock the more common case (destroyed DMS bootstrap). Co-authored-by: Isaac <no-reply@databricks.com>
Collaborator
Integration test reportCommit: 0336c85
29 interesting tests: 27 FAIL, 1 KNOWN, 1 SKIP
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Fixes a bug where enabling DMS recording (
experimental.record_deployment_history) on a deployment fails when the local state cache still has resources, even if the remote deployment was destroyed. The fix nullifies local state when recording is enabled, treating the state file as a tombstone that only carries the feature marker and header.The Problem
When a DMS deployment is destroyed on the service, the local
resources.jsonis a cache that can retain stale resources. Attempting to redeploy with DMS enabled would fail with:This error was caused by a guard that checked
recording && !recorded && len(db.Data.State) > 0. While the guard was originally designed to prevent enabling DMS on existing non-DMS deployments (creating resources a second time), it also blocked the legitimate case of a destroyed DMS deployment being rebuilt.The Solution
When opening a deployment state with recording enabled, nullify the local state. The service becomes the source of truth:
dmsDeploymentIDis non-empty:ListResourcesfetches resources from the servicedmsDeploymentIDis empty: no resources are loaded (fresh or destroyed deployment)This allows the bootstrap path to be taken (
recording && !recorded && len(db.Data.State) == 0) instead of erroring.Tradeoff
Nullifying local state removes the guard against enabling DMS on an existing non-DMS deployment (no service node, but resources cached locally). This could:
However, this is an acceptable tradeoff to unblock the more common and important case: recovering destroyed DMS deployments. Users who need to migrate from non-DMS to DMS should explicitly destroy the bundle first.
Changes
bundle/direct/dstate/state.go: Nullify local state whenrecordingis truebundle/direct/dstate/state_test.go: Add unit test verifying preconditionsacceptance/bundle/dms/existing-state/output.txt: Updated golden (reflecting changed guard behavior)Testing
go test ./bundle/direct/dstate/...This pull request and its description were written by Isaac.