You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Each initializer has a unique name, which gets automatically generated using `<workspace-path-of-WorkspaceType>:<WorkspaceType-name>`. So for example, if you were to apply the aforementioned WorkspaceType on the root workspace, your initializer would be called `root:example`.
26
26
27
-
Since `WorkspaceType.spec.initializer` is a boolean field, each WorkspaceType comes with a single initializer by default. However each WorkspaceType inherits the initializers of its parent workspaces. As a result, it is possible to have multiple initializers on a WorkspaceType, but you will need to nest them.
28
-
Here is a example:
27
+
Since `WorkspaceType.spec.initializers` is a boolean field, each WorkspaceType comes with a single initializer by default. However each WorkspaceType inherits the initializers of its parent WorkspaceType. As a result, it is possible to have multiple initializers on a WorkspaceType using [WorkspaceType Extension](../../concepts/workspaces/workspace-types.md#workspace-type-extensions-and-constraints)
29
28
30
-
1. In `root` workspace, create a new WorkspaceType called `parent`. You will receive a `root:parent` initializer
31
-
2. In the newly created `parent` workspace, create a new WorkspaceType `child`. You will receive a `root:parent:child` initializer
32
-
3. Whenever a new workspace is created in the child workspace, it will receive both the `root:parent` as well as the `root:parent:child` initializer
29
+
In the following example, `child` inherits the initializers of `parent`. As a result, child workspaces will have the `root:child` and `root:parent` initializers set.
30
+
31
+
```yaml
32
+
apiVersion: tenancy.kcp.io/v1alpha1
33
+
kind: WorkspaceType
34
+
metadata:
35
+
name: child
36
+
spec:
37
+
initializer: true
38
+
extend:
39
+
with:
40
+
- name: parent
41
+
path: root
42
+
```
33
43
34
44
### Enforcing Permissions for Initializers
35
45
@@ -66,7 +76,7 @@ roleRef:
66
76
67
77
## Writing Custom Initialization Controllers
68
78
69
-
### Responsibilities Of Custom Intitialization Controllers
79
+
### Responsibilities Of Custom Initialization Controllers
70
80
71
81
Custom Initialization Controllers are responsible for handling initialization logic for custom WorkspaceTypes. They interact with kcp by:
72
82
@@ -88,163 +98,16 @@ $ kubectl get workspacetype example -o yaml
You can use this url to construct a kubeconfig for your controller. To do so, use the url directly as the `cluster.server` in your kubeconfig and provide a user with sufficient permissions (see [Enforcing Permissions for Initializers](#enforcing-permissions-for-initializers))
104
+
You can use this url to construct a kubeconfig for your controller. To do so, use the url directly as the `cluster.server` in your kubeconfig and provide the subject with sufficient permissions (see [Enforcing Permissions for Initializers](#enforcing-permissions-for-initializers))
95
105
96
106
### Code Sample
97
107
98
108
When writing a custom initializer, the following needs to be taken into account:
99
109
100
-
* We strongly recommend to use the kcp [initializingworkspace multicluster-provider](github.com/kcp-dev/multicluster-provider) to build your custom initializer
110
+
* We strongly recommend to use the kcp [initializingworkspace multicluster-provider](https://github.com/kcp-dev/multicluster-provider) to build your custom initializer
101
111
* You need to update LogicalClusters using patches; They cannot be updated using the update api
102
112
103
-
Keeping this in mind, you can use the following example as a starting point for your intitialization controller
Keeping this in mind, you can use the [multicluster-provider initializingworkspaces example](https://github.com/kcp-dev/multicluster-provider/tree/main/examples/initializingworkspaces) as a starting point for your initialization controller
0 commit comments