Databricks

Emulates both layers of Azure Databricks — the ARM workspace control plane (Microsoft.Databricks/workspaces) that provisions a workspace and the workspace data plane (Databricks REST API) that runs clusters, jobs, and more inside it. The real databricks-sdk-go, pointed at the emulator, creates a workspace over ARM, discovers its URL, and then drives the data plane against in-memory state.

Reach for it in tests when your code stands up a workspace and then operates on it — creating clusters, submitting jobs, managing policies — so you can cover that full ARM-then-data-plane flow without a real Databricks account. Both layers share one backend, so a workspace created over ARM is immediately usable over the data-plane API.

Drive both layers with the real SDK#

Register the same mock as both the ARM control plane and the data plane, then let databricks-sdk-go walk the real flow — provision over ARM, read the returned URL, operate against it. The config-discovery endpoint is served automatically, so no manual workspace configuration is needed:

import (
    "github.com/stackshy/cloudemu/v2"
    azureserver "github.com/stackshy/cloudemu/v2/server/azure"
)

cp := cloudemu.NewAzure()
ts := httptest.NewTLSServer(azureserver.New(azureserver.Drivers{
    Databricks:          cp.Databricks, // ARM control plane
    DatabricksDataPlane: cp.Databricks, // workspace data plane (same backend)
}))

// databricks-sdk-go clients:
//   1. Create the workspace via ARM (armdatabricks).
//   2. Read the returned WorkspaceURL, which points at this server's data plane.
//   3. Call clusters/jobs/etc. against that URL — the SDK's config-discovery
//      endpoint (/.well-known/databricks-config) is served automatically.

See the SDK-Compat Server page for the Azure TLS setup.

Drive both layers with the Portable Go API#

The azure.Databricks mock implements both driver interfaces, so you can provision a workspace and operate its data plane directly — create the workspace, spin up a cluster, then kick off a job run:

import dbxdriver "github.com/stackshy/cloudemu/v2/services/databricks/driver"

ws, _ := azure.Databricks.CreateWorkspace(ctx, dbxdriver.WorkspaceConfig{
    Name: "analytics", ResourceGroup: "rg-prod", Location: "eastus",
})

cluster, _ := azure.Databricks.CreateCluster(ctx, dbxdriver.ClusterConfig{
    Name: "etl", SparkVersion: "14.3.x-scala2.12",
    NodeTypeID: "Standard_D4s_v3", NumWorkers: 2,
})

runID, _ := azure.Databricks.RunJobNow(ctx, jobID)

Behavior & fidelity#

• Deterministic workspace URL. CreateWorkspace synthesizes an adb-{workspaceId}.{shard}.azuredatabricks.net host with a numeric workspace ID derived from the resource group + name, so identical inputs always yield the same URL. The /.well-known/databricks-config host-metadata endpoint is served so databricks-sdk-go locates the workspace automatically.
• Shared backend. The ARM control plane and the data plane read and write the same in-memory state, so a workspace created over ARM is immediately usable over the data-plane API.
• SDK-compat status — Live. The real databricks-sdk-go drives it end-to-end via the SDK-compat server: the ARM control plane (CreateWorkspace, GetWorkspace, UpdateWorkspaceTags, DeleteWorkspace, ListWorkspacesByResourceGroup, ListWorkspaces) and the data plane — Clusters (/api/2.1/clusters/*), Instance pools (/api/2.0/instance-pools/*), Jobs (/api/2.2/jobs/*), Runs (/api/2.2/jobs/runs/*), Cluster policies, Libraries, and Permissions — with DBFS, Repos, Git credentials, Secrets, Workspace files (WSFS), SCIM, Tokens, Pipelines, Query history, SQL Warehouses, Serving endpoints, and Unity Catalog (+ UC storage) wired in as nested handlers. The same semantics are available through the Portable Go API above.