Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

📝 Mount API POC #3232

Draft
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

mjudeikis
Copy link
Contributor

Summary

Thinking how best to promote mounts into more native way of doing things in kcp.
Somehow logical steps in my head currently are:

  1. Extend WorkspaceType with Mount *metav1.TypeMeta json:"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.

  2. Extend Workspace with Mount *metav1.ObjectMeta json:"mount,omitempty"`` where we specify what specific object we refer to. It would when be resolved into statuses as we do now.

  3. We would need to relax URL validation for mount types and basically use spec.url for mount URL if its mountpoint.

This is very much brain-dump to kick-off discussions. @sttts @embik

Related issue(s)

Fixes #

Release Notes

NONE

@kcp-ci-bot kcp-ci-bot added do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. release-note-none Denotes a PR that doesn't merit a release note. dco-signoff: yes Indicates the PR's author has signed the DCO. labels Dec 21, 2024
@kcp-ci-bot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please ask for approval from mjudeikis. For more information see the Kubernetes Code Review Process.

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 /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@kcp-ci-bot
Copy link
Contributor

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

@kcp-ci-bot kcp-ci-bot added kind/api-change Categorizes issue or PR as related to adding, removing, or otherwise changing an API size/S Denotes a PR that changes 10-29 lines, ignoring generated files. labels Dec 21, 2024
// +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"`
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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"`
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

how is this related to workspace types?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In my mind type and mount are mutual exclusive, i.e. WorkspaceTypes are actually LogicalClusterTypes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
dco-signoff: yes Indicates the PR's author has signed the DCO. do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. kind/api-change Categorizes issue or PR as related to adding, removing, or otherwise changing an API release-note-none Denotes a PR that doesn't merit a release note. size/S Denotes a PR that changes 10-29 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants