📝 Mount API POC #3232
📝 Mount API POC #3232
Conversation
kcp-ci-bot
added
do-not-merge/work-in-progress
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
Skipping CI for Draft Pull Request. |
kcp-ci-bot
added
kind/api-change
| // +optional | ||
| // +kubebuilder:validation:XValidation:rule="!has(oldSelf.name) || !has(self.name) || self.name == oldSelf.name",message="name is immutable" | ||
| // +kubebuilder:validation:XValidation:rule="!has(oldSelf.namespace) || !has(self.namespace) || self.namespace == oldSelf.namespace",message="namespace is immutable" | ||
| Mount *metav1.ObjectMeta `json:"mount,omitempty"` |
There was a problem hiding this comment.
Doesn't this need some higher-level CEL rule to make it mutual exclusive and bound to type?
| // If set, the workspace will be backed by a mount. | ||
| // | ||
| // +optional | ||
| Mount *metav1.TypeMeta `json:"mount,omitempty"` |
There was a problem hiding this comment.
how is this related to workspace types?
There was a problem hiding this comment.
This would be something like kind: mounts.contrib.kcp.io so every workspace initiated via this type just needs to carry name only for the kind. basically bounts workspaceType to mount implementation kind. Still thinking if this is a good idea.
But if we keep Kind of mount object inside workspace spec, workspace Type is not even used.
maybe at the workspace level:
Type WorkspaceTypeReference should become with Kind: Mount,LogicalCluster ?
There was a problem hiding this comment.
something like:
spec:
URL: https://192.168.3.55:6443/clusters/root:consumer
cluster: ofebwh0c93o6swd3
type:
name: organization
path: root
Would become:
spec:
URL: https://192.168.3.55:6443/clusters/root:consumer
cluster: ofebwh0c93o6swd3
type:
kind: WorkspaceType
name: organization
path: root
and
spec:
URL: https://192.168.3.55:6443/clusters/root:consumer
cluster: ofebwh0c93o6swd3
type:
kind: Mount
name: mountBob
kind: mounts.contrib.kcp.io
version: v1alpha1
There was a problem hiding this comment.
In my mind type and mount are mutual exclusive, i.e. WorkspaceTypes are actually LogicalClusterTypes.
There was a problem hiding this comment.
So do you think its root level new field in Workspace? Any suggestions how this could be named considering type is taken? :) Or just mount:
Summary
Thinking how best to promote mounts into more native way of doing things in kcp.
Somehow logical steps in my head currently are:
Extend WorkspaceType with
Mount *metav1.TypeMetajson:"mount,omitempty"`` telling which flavour it is.Maybe even add "SubType: LogicalCluster,Mount"? But think this is already too much. If Mount is set, we expect everything else to be nil/not set. It would specific Kind for mount object, but not name.
Extend Workspace with
Mount *metav1.ObjectMetajson:"mount,omitempty"`` where we specify what specific object we refer to. It would when be resolved into statuses as we do now.We would need to relax URL validation for
mounttypes and basically usespec.urlfor mount URL if its mountpoint.This is very much brain-dump to kick-off discussions. @sttts @embik
Related issue(s)
Fixes #
Release Notes