bundle: record auto-migration compatibility telemetry on deploy#5439
bundle: record auto-migration compatibility telemetry on deploy#5439shreyas-goenka wants to merge 1 commit into
Conversation
60fba4e to
cc47397
Compare
e7e9e83 to
7c783aa
Compare
|
Commit: 313ab31
23 interesting tests: 15 SKIP, 7 KNOWN, 1 flaky
Top 28 slowest tests (at least 2 minutes):
|
cc47397 to
b2c7271
Compare
7c783aa to
5e587f0
Compare
b2c7271 to
c2aa303
Compare
5e587f0 to
2cd3ef3
Compare
c2aa303 to
b1d732b
Compare
2cd3ef3 to
07abec1
Compare
b1d732b to
9e2f26b
Compare
07abec1 to
26c3380
Compare
9e2f26b to
00c5b7b
Compare
26c3380 to
30172b5
Compare
00c5b7b to
addcb6a
Compare
30172b5 to
3646391
Compare
46c9c69 to
bf9f878
Compare
bf9f878 to
abe3dfb
Compare
| has_serverless_compute true | ||
| local.cache.attempt true | ||
| local.cache.miss true | ||
| permissions_section_is_set false |
There was a problem hiding this comment.
Because permissions are not set here, by definition state_path_acl_exceeds_permissions is true.
There was a problem hiding this comment.
Analysis needs to take this into account when looking at state_path_acl_exceeds_permissions.
Can we choose to not emit it when permissions are not set?
There was a problem hiding this comment.
Simpliefied. We only record a single is_auto_migration_compatible. All the rich logic lives in the CLI.
permissions block.
Approval status: pending
|
abe3dfb to
3c6a454
Compare
3c6a454 to
681e089
Compare
| has_serverless_compute true | ||
| local.cache.attempt true | ||
| local.cache.miss true | ||
| permissions_section_is_set false |
There was a problem hiding this comment.
Analysis needs to take this into account when looking at state_path_acl_exceeds_permissions.
Can we choose to not emit it when permissions are not set?
| - level: CAN_MANAGE, group_name: data-engineers | ||
|
|
||
| Add them to your bundle permissions or remove them from the folder. | ||
| See https://docs.databricks.com/dev-tools/bundles/permissions |
There was a problem hiding this comment.
It is odd to see the same warning twice here. Anything we can do about it?
There was a problem hiding this comment.
That is by design - we get two warnings, one for the root path and one for the state path (because they are different). The naming is a bit confusing because the target name is state_path as well.
| statePath := b.Config.Workspace.StatePath | ||
| for i, p := range bundlePaths { | ||
| if pathContains(p, statePath) && !libraries.IsWorkspaceSharedPath(p) { | ||
| b.Metrics.SetBoolValue(metrics.StatePathAclExceedsPermissions, len(results[i]) > 0) |
There was a problem hiding this comment.
This depends on the presence or absence of diags for a path? Seems brittle if so.
| * Set the default `data_security_mode` to `DATA_SECURITY_MODE_AUTO` in bundle templates ([#5452](https://github.com/databricks/cli/pull/5452)). | ||
| * Mark vector search index index_subtype as backend_default to prevent drift after deployment ([#5454](https://github.com/databricks/cli/pull/5454)). | ||
| * `bundle deployment migrate`: handle resources added to or removed from `databricks.yml` since the last Terraform deploy ([#5463](https://github.com/databricks/cli/pull/5463)). | ||
| * Warn during `bundle deploy` when a workspace folder used by the bundle grants broader permissions than the bundle's top-level `permissions` section declares, for example through permissions inherited from a parent folder ([#5439](https://github.com/databricks/cli/pull/5439)). |
There was a problem hiding this comment.
If I understand correctly, we already do this and this is not new. The only difference is that we record it.
There was a problem hiding this comment.
We only warn in the bundle validate command today, where we fetch the permissions on all folders. This is new because now we also warn on bundle deploy.
681e089 to
e6521fb
Compare
ApplyWorkspaceRootPermissions already calls SetPermissions on each workspace path prefix during deploy; the response carries the folder's resulting ACL. Reusing it (no extra API call), we record whether this deploy is compatible with an automatic DMS migration — i.e. whether, after migration, the deployment state folder can be managed by only the declared permissions plus the deployer (allowed without being declared only when the state is under the deployer's home). Exactly one verdict is recorded per deploy: - is_definitely_auto_migration_compatible: folder ACL observed and compatible. - is_not_auto_migration_compatible: folder ACL observed (or known statically for /Workspace/Shared) and not compatible. - is_maybe_auto_migration_compatible: no permissions section, so the folder was not synced and the ACL is unobserved; resolving it needs a GetPermissions call. Aggregate by deployment ID: a deployment (bundle target) is auto-migratable only if all of its deploys are compatible. The fake test server now models home-folder ownership (a directory under /Workspace/Users/<owner> returns that owner's inherited CAN_MANAGE), so the acceptance test exercises the full matrix via bundle paths and declared permissions alone. Co-authored-by: Shreyas Goenka <shreyas.goenka@databricks.com>
Telemetry only. During
bundle deploywe reuse the existingSetPermissionsresponse (no extra API call) to record whether this deploy is compatible with an automatic DMS migration — i.e. whether the deployment state folder can be managed by only the declaredpermissionsplus the deployer (allowed undeclared only under their own home/Workspace/Users/<deployer>;/Workspace/Sharedneedsusers: CAN_MANAGE).Exactly one verdict per deploy (
bool_values):is_definitely_auto_migration_compatible— ACL observed and compatible.is_not_auto_migration_compatible— observed (or statically known for shared) and not.is_maybe_auto_migration_compatible— no permissions section, so the ACL is unobserved.Plus
state_path_is_shared. Aggregate by deployment ID (a bundle target is migratable only if all its deploys are).Tested by one acceptance test over the location × permissions matrix; the fake server models home-folder ownership so cases are driven by bundle config alone.