Break out why a DABs deployment is or is not DMS compatible#5668
Draft
shreyas-goenka wants to merge 1 commit into
Draft
Break out why a DABs deployment is or is not DMS compatible#5668shreyas-goenka wants to merge 1 commit into
shreyas-goenka wants to merge 1 commit into
Conversation
The merged dms_compat_* verdict tells us whether a deploy is auto-migration compatible, but not why. This adds an independent boolean breakdown recorded on every deploy so the population can be sliced directly: - permissions_section_set: separates the always-compatible no-permissions population from declared-permissions deploys (both land on dms_compat_auto). - state_path_in_deployer_home / state_path_in_other_user_home: where the deployment state lives (with the existing state_path_is_shared; all false means some other /Workspace folder). - dms_undeclared_deploying_user / _other_user / _service_principal / _group: which principal types hold undeclared write access to the state folder — the access an auto-migration governed by the permissions section would drop. These co-occur. All keys go through the existing BoolValues map, so no telemetry proto change is needed. Exact per-type counts would need a numeric proto field and are left out. Covered by the existing deploy-workspace-folder-permissions acceptance test (extended with an other-user-home target) plus unit tests for the principal-type classification and home-owner parsing. Co-authored-by: Shreyas Goenka <shreyas.goenka@databricks.com>
Collaborator
Integration test reportCommit: e1812fa
20 interesting tests: 13 SKIP, 7 RECOVERED
Top 21 slowest tests (at least 2 minutes):
|
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.
Break down why DABs deployments are not compatible with DMS
permissions_section_set— separates the always-compatible no-permissions population from declared-permissions deploys (both land ondms_compat_auto).state_path_in_deployer_home/state_path_in_other_user_home— where the deployment state lives (with the existingstate_path_is_shared; all false ⇒ some other/Workspacefolder).dms_undeclared_deploying_user/dms_undeclared_other_user/dms_undeclared_service_principal/dms_undeclared_group— which principal types hold undeclared write access to the state folder, i.e. the access an auto-migration governed by the permissions section would drop. These co-occur.This gives the "numbers" dimension as per-type presence flags. Exact integer counts (e.g. how many SPs) would need a numeric telemetry proto field — left out to avoid the universe proto dependency; easy follow-up if wanted.
Testing
deploy-workspace-folder-permissionsacceptance test extended with an other-user-home target; the matrix now exercises every breakdown key: