Add workspace root kep - #10
Conversation
kcp-ci-bot
added
dco-signoff: yes
|
After talking some more @mjudeikis and I both are not budging from our positions. Instead we are going to make two feature gates. This still allows kcp instances in which users can create their own roots with a random name as well as instances where platform owners can decide legible names. The only drawback of this is that these two system can then not be mixed. But all other options that come to mind (two types, two APIs, ...) do not sit well. |
|
The only drawback of this is that these two system can then not be mixed. But all other options that come to mind (two types, two APIs, ...) do not sit well. They can be mixed. There is nothing in there that would make it them not mix. One can use one mode, and switch to another midd operations and have both. Is it nice? No :D |
Technically speaking yes, practically speaking that is horrifying. :D |
mjudeikis
added
the
do-not-merge/hold
| // Cluster is an optional name for the logical cluster path. | ||
| // If not provided, a random base36 identifier will be generated. | ||
| // +optional | ||
| Cluster string `json:"cluster,omitempty"` |
There was a problem hiding this comment.
| // Cluster is an optional name for the logical cluster path. | |
| // If not provided, a random base36 identifier will be generated. | |
| // +optional | |
| Cluster string `json:"cluster,omitempty"` | |
| // ClusterName is an optional name for the logical cluster path. | |
| // If not provided, a random base36 identifier will be generated. | |
| // +optional | |
| ClusterName string `json:"clusterName,omitempty"` |
Since we call it clusterName everywhere else - or is there precedent for just cluster in the logical cluster?
| // URL is the base URL for accessing workspaces in this tree via the front-proxy. | ||
| // Format: https://<front-proxy>/clusters/<rootPath> | ||
| // This is set by the provisioning controller based on the front-proxy configuration. | ||
| // Note: All front-proxies in a kcp deployment must share the same external URL. |
There was a problem hiding this comment.
| // Note: All front-proxies in a kcp deployment must share the same external URL. |
I think this is something that should be set in stone in kcp-dev/kcp#3837 rather than in an otherwise mostly unrelated part.
| #### Feature Gate: `LogicalRootRandomNames` (default: enabled) | ||
|
|
||
| When enabled, the root path identifier is always randomly generated (base36), regardless of | ||
| the `metadata.name` of the LogicalRoot object. This prevents: | ||
| - Different shards from claiming the same prefix | ||
| - Predictable/guessable root identifiers | ||
| - Collisions when multiple controllers provision roots concurrently | ||
|
|
||
| Example: | ||
| ```yaml | ||
| apiVersion: forest.tenancy.kcp.io/v1alpha1 | ||
| kind: LogicalRoot | ||
| metadata: | ||
| name: company-a # Object name for management | ||
| spec: | ||
| cluster: "" # Empty = randomly generated. Not allowed to specify when random names enabled. | ||
| status: | ||
| rootPath: a1b2c3d4 # Randomly generated, used for access | ||
| ``` | ||
|
|
||
| #### Feature Gate: `LogicalRootDeterministicNames` (default: disabled) | ||
|
|
||
| When enabled (and `LogicalRootRandomNames` disabled), the root path is derived from | ||
| `metadata.name`. This is useful for deployments where: | ||
| - Predictable paths are required for automation | ||
| - A single controller manages all root provisioning | ||
| - Human-readable paths are preferred over security-by-obscurity |
There was a problem hiding this comment.
Not a fan of two possibly conflicting feature gates. Sure we can put a check in code but I don't really like that behaviour.
If we enable the forest API by default random names should just be on and a feature gate should allow users to set spec.cluster. LogicalRootAllowCustomNames?
There was a problem hiding this comment.
Following that if spec.cluster is empty kcp generates a name.
| #### Other Naming Considerations | ||
|
|
||
| - **Cluster**: The `spec.cluster` field specifies the desired logical cluster path. If empty, | ||
| a random base36 identifier is generated (when `LogicalRootRandomNames` is enabled). | ||
| - **Root workspace**: The system `root` workspace continues to exist for system resources. | ||
| Organizations get their own independent trees. | ||
|
|
There was a problem hiding this comment.
| #### Other Naming Considerations | |
| - **Cluster**: The `spec.cluster` field specifies the desired logical cluster path. If empty, | |
| a random base36 identifier is generated (when `LogicalRootRandomNames` is enabled). | |
| - **Root workspace**: The system `root` workspace continues to exist for system resources. | |
| Organizations get their own independent trees. |
The first point is already discussed above, the second point is irrelevant imho
| ### Alternative 1: Modify Workspace API with `--root` flag | ||
|
|
||
| ```bash | ||
| kubectl ws create bar --enter --root |
There was a problem hiding this comment.
| kubectl ws create bar --enter --root | |
| kubect create-workspace bar --enter --root |
ws create is deprecated
|
/approve |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: xrstf The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
kcp-ci-bot
added
the
approved
4 participants
No description provided.