Asset Bundle Deployment always triggers Cluster restart (Direct deployment)

[leekennett]

Describe the issue

Using databricks bundle deploy with direct engine is always trigging a cluster restart.
Similar to - #3286
Bundle validates successfully.
No changes to the cluster.
databricks bundle plan shows the cluster is going to get updated.

Checking the cluster history shows identical pre/post json configurations aside from:
"release_version": "17.3.9"

which appears to be some configuration that cannot be specified.

Configuration

Databricks CLI v0.284.0

Cluster definition

resources: clusters: cluster-developer: cluster_name: "cluster-developer" policy_id: ${var.policy_general} spark_version: ${var.spark_version} driver_node_type_id: "Standard_D4pds_v6" node_type_id: "Standard_D4pds_v6" kind: "CLASSIC_PREVIEW" enable_local_disk_encryption: false is_single_node: true num_workers: 0 spark_conf: "spark.master": "local[*, 4]" "spark.databricks.cluster.profile": "singleNode" custom_tags: compute_name: "cluster-developer" ResourceClass: SingleNode autotermination_minutes: 60 data_security_mode: SINGLE_USER single_user_name: ${workspace.current_user.userName}

Steps to reproduce the behavior

1. Run databricks bundle deploy ...
2. Observe cluster update behaviour

Expected Behavior

Cluster should not update/restart. This adds 2+minutes on every iteration using bundles and is annoying.

Actual Behavior

Cluster restarts.

OS and CLI version

Databricks CLI v0.284.0

[denik]

Thanks for the report. Could you include bundle plan -o json output as well? There is "changes" section that shows which field triggered the update.

[leekennett]

Ah!!

Thank you for that.
I see now there's a custom tag in the policy but not defined in the resource definition.

Policy has a custom tag defined

"custom_tags.env": {
            "type": "fixed",
            "value": "dev"
        },

and tags are defined in the resource as well

custom_tags:
            compute_name: cluster-developer
            ResourceClass: SingleNode

That combination resulted in the dev tagged getting removed on bundle + reapplied by policy causing the restart.

Solvable by either removing the tag from the policy, or redefining it in the resource definition. Now it successfully shows it as skipping.
I suppose this can be closed then, assuming that's the expected behavior.