Skip to content

Commit 2309e76

Browse files
authored
Merge pull request #3324 from Soot3/main
📖 docs Update workspace-types.md
2 parents 28f5a2c + 68bef78 commit 2309e76

File tree

1 file changed

+65
-0
lines changed

1 file changed

+65
-0
lines changed

docs/content/concepts/workspaces/workspace-types.md

+65
Original file line numberDiff line numberDiff line change
@@ -151,3 +151,68 @@ that the system workspace exists.
151151
As an example, the `system:admin` workspace exists for administrative objects
152152
that are scoped to the local shard (e.g. `lease` objects for kcp internal controllers if
153153
leader election is enabled). It is accessible via `/clusters/system:admin`.
154+
155+
# Workspace Type Extensions and Constraints
156+
kcp offers extensions and constraints that enable you inherit functionality from other
157+
workspace types and create custom workspace hierarchies for your organizational structure.
158+
159+
A `WorkspaceType` can extend one or more other `WorkspaceTypes` using the `spec.extend.with`
160+
field.
161+
162+
**Example**
163+
```yaml
164+
apiVersion: tenancy.kcp.io/v1alpha1
165+
kind: WorkspaceType
166+
metadata:
167+
name: sample
168+
spec:
169+
extend:
170+
with:
171+
- name: universal
172+
- name: custom
173+
```
174+
In this example, the `sample` workspace type:
175+
* inherits [initializers](./workspace-initialization.md) from the extended types
176+
* is considered as an extended type during type constraint evaluation
177+
178+
You can also extend `WorkspaceTypes` from other workspaces by specifying the path:
179+
180+
```yaml
181+
apiVersion: tenancy.kcp.io/v1alpha1
182+
kind: WorkspaceType
183+
metadata:
184+
name: custom
185+
spec:
186+
extend:
187+
with:
188+
- name: standard
189+
path: root:base
190+
```
191+
## Workspace Constraint Mechanisms
192+
KCP provides two primary constraint mechanisms for workspace types:
193+
* `limitAllowedChildren`: Controls which workspace types can be created as children.
194+
* `limitAllowedParents`: Controls which workspace types can serve as parents.
195+
196+
```yaml
197+
...
198+
spec:
199+
limitAllowedParents:
200+
types:
201+
- name: sample
202+
path: root
203+
limitAllowedChildren:
204+
types:
205+
- name: custom
206+
path: root
207+
```
208+
You can also block all types from being used as children:
209+
```yaml
210+
apiVersion: tenancy.kcp.io/v1alpha1
211+
kind: WorkspaceType
212+
metadata:
213+
name: leaf-workspace
214+
spec:
215+
limitAllowedChildren:
216+
none: true
217+
```
218+
This ensures that no other workspace type can be created as a child of `leaf-workspace`.

0 commit comments

Comments
 (0)