Data Model
Last updated
Last updated
PrimeHub does not have its database. The data is stored in keycloak's object and kubernetes object. The following diagram is a brief view of the data.
Keycloak: We store user
and group
data. And assign a group to specific roles to bind this group to images, volumes, and instance types.
Kubernetes: The definition of image
, volume
, instance type
is stored as CRD (Custom Resource Definition) objects respectively. And the secret
is stored by the kubernetes builtin secret object.
A user in PrimeHub corresponds to a user in Keycloak's primehub realm.
When a user is created via Admin UI, under the hood a user is created in Keycloak via API.
When a user is connected to existing groups via Admin UI, a user is assigned to groups in Keycloak via API.
Attributes
locale
personalDiskQuota
, when a user is created, there is a 1G volume allocated by default for the user.
Role
If a user has admin privileges, it must have realm-admin
in realm-management Client Roles
.
A group in PrimeHub represents a group in Keycloak correspondingly.
When a group is created via Admin UI, a group data is created in Keycloak via API.
Attributes A group can have attributes that are stored in Keycloak such as canUseCpu
, cpuQuota
, gpuQuota
, diskQuota
, displayName
and so on.
Role Mappings In Keycloak, a group can be assigned Realm Roles
, all of the members in a group inherit the same realm roles by default.
Members A member who is a user in a group.
A hidden Group from Admin UI, everyone
, which every created user must join is created for PrimeHub by default. The purpose is that when the flag Global
is enabled in instance type
/image
/volume
via Admin UI, there is a corresponding realm role, <type>:xxx
, assigned to the group everyone
.
When instance type
, image
or volume
is created via Admin UI, there are two things done at the background,
A CRD object is created via Kubernetes.
A CRD object stores settings which are configured via Admin UI such as Basic Info
, Toleration
and NodeSelector
and so on. You can use commands below to list all of the stored CRDs.
A dedicated realm-role is also created correspondingly in Keycloak.
A name of Realm Role comes with a prefix which indicates instance type
, image
, or volume
.
it:xxx, prefix it
represents instance type
.
img:xxx, prefix img
represents image
.
ds:[rw:]xxx, prefix ds
represents volume
, rw
: read-write, read-only by default. A volume is connected to an existing group via Admin UI it is assigned to a group correspondingly in Keycloak via API.
For advanced usage, we can add a prefix to these roles. For example,
it:cpu-only
with prefixcluster1
iscluster1:it:cpu-only
. Please refer to helm customization relative document.
Once a/an instance type
/image
/volume
is connected to existing groups, the dedicated Realm Role is assigned to the groups.
Therefore, all of the members(a.k.a users) of the group can see it from the menu Server Options
of JupyterHub spawner. That also explains the relation between the flag Global
and the hidden group everyone.
.
When a secret
is created via Admin UI, the settings are stored as a secret
in Kubernetes. You can use command below to list them.