Account level groups

[andreapeterson]

When I query my user from an account client and workspace client, I get different answers. Why is this?  In addition, why can I only see some account level groups from my workspace, and not others?

[Shua42]

Hi @andreapeterson ,

This is because the users scoped to the workspace and account may differ. There can be users that are part of the account but not assigned to a given workspace, or different asignments for different users. More information on the difference is available here: https://docs.databricks.com/aws/en/admin/users-groups/#assign-users-to-databricks .

You should expect to see a difference, unless every user and group is also assigned to the given workspace. Based on the identity management you have set up, do you expect there to be a difference?

[vr · Accepted solution]

If you have a relatively modern Databricks instance, when you create a group in workspace UI, it creates an account-level group (which you can see in "Source" column – it says "Account"). So this process essentially consists of two steps: 1) create account-level group if it does not exist; 2) add the group into the workspace. The step #2 is only a display record, it does not create an actual container. (You still can create a workspace-level group through API, but in UI this capability is not available now).

An account-level group can be added to a workspace or may be not added. The content of the group is stored in the account, and will be synchronized across all workspaces. Even if you remove a group and add it back, you will see all users inside, because it comes from the account.

The same applies to all three categories of identities: groups, users, service principals. The main source of truth is the account, but there is also an association between the identity and the workspace, which "mirrors" the account data from the account into the workspace, plus allows for some workspace-level settings. With users and service principals you can clearly see this in the UI, because when you add them to the workspace, the experience will be different for users/SPs already existing in account and not existing. The groups are different in this regard, because the UI just allows you to specify name, and if you enter the account-level group name – boom, you got account content all of sudden. I am not a big fun of how this all is implemented in Databricks; as a Developer I like better the principle of the least astonishment and being explicit rather implicit, but, I guess, this was the sacrifice they had to make when transitioning from the old single-workspace setups to enterprise account setups while trying to keep the existing UX.

So, I guess, the info above gives you some clues why you may see differences in account and workspace client's responses. Account shows "global" user properties, and workspace shows properties set for the user in this workspace (plus duplicating some account-level info).

P.S. Everything above applies to Azure, I don't know if it works the same in AWS.

[andreapeterson]

Wow vr this was so incredibly helpful I cannot thank you enough!! This helped me really wrap my head around workspace versus account and does explain the discrepancies between the two, very confusing, especially for example when you add a group via ui in the workspace - its account level, but you can create a workspace level through api only. Bottom line, as you said the main source of truth is the account. Thank you!!

[vr]

Yeah, and the most mind-bending things occur when you happen to create both account and workspace level group with the same name 😀 In this case UI does not warn you in any way, but just shows the account group only. I once create a workspace group with Terraform, added users (which passed successfully), and was scratching my head desperately a whole day trying to understand why I don't see any users in UI.

[andreapeterson]

HAHA that is funny that is great, but I guess it had to happen so you can spread your wealth of knowledge as you do now