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

Add the vineyard runtime CRD definitions. #3555

Merged

Conversation

dashanji
Copy link
Contributor

Ⅰ. Describe what this PR does

Add the vineyard runtime CRD definitions.

Ⅱ. Does this pull request fix one issue?

Fixes parts of #3528

Copy link

fluid-e2e-bot bot commented Nov 17, 2023

Hi @dashanji. Thanks for your PR.

I'm waiting for a fluid-cloudnative member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

Copy link

codecov bot commented Nov 18, 2023

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (6e500f9) 64.13% compared to head (46bb89b) 64.14%.

Additional details and impacted files
@@            Coverage Diff             @@
##           master    #3555      +/-   ##
==========================================
+ Coverage   64.13%   64.14%   +0.01%     
==========================================
  Files         441      442       +1     
  Lines       26572    26574       +2     
==========================================
+ Hits        17042    17046       +4     
+ Misses       7525     7524       -1     
+ Partials     2005     2004       -1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

// Resources contains the resource requirements and limits for the Vineyard Master.
// Default is not set.
// +optional
Resources corev1.ResourceRequirements `json:"resources,omitempty"`
Copy link
Collaborator

Choose a reason for hiding this comment

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

I think master, worker and fuse needs configuring Resources.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

One consideration that does not allow the master to configure resources is that users need to consider the relationship between shared memory and resources memory. If only keep the shared memory configuration, it will be more transparent to users.

Copy link
Collaborator

Choose a reason for hiding this comment

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

I think the meaning of transparent is that the users don't need to configure it by default, but they can do it when they really need it.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Okay, it looks good to me.

// vineyardd.reserve.memory: "true"
//
// +optional
Properties map[string]string `json:"properties,omitempty"`
Copy link
Collaborator

Choose a reason for hiding this comment

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

How about renaming properties to options? And I think master spec also need options which can provides flexibility for future.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Make sense to me.

@cheyang
Copy link
Collaborator

cheyang commented Nov 18, 2023

@dashanji please fix github action/lint by running make update-crd.

GO111MODULE=off /home/runner/work/fluid/fluid/bin/controller-gen "crd" rbac:roleName=manager-role webhook paths="./..." output:crd:artifacts:config=config/crd/bases
cp config/crd/bases/* charts/fluid/fluid/crds
 M config/crd/bases/data.fluid.io_vineyardruntimes.yaml
?? charts/fluid/fluid/crds/data.fluid.io_vineyardruntimes.yaml
CRD validation failed. Please use 'make update-crd' to keep CRDs latest

@dashanji
Copy link
Contributor Author

@cheyang Could you please take another look at this? Thanks.

// If set to false, the Etcd component will not be deployed,
// which means the Vineyard Worker component will use an external Etcd cluster.
// +optional
Enabled bool `json:"enabled,omitempty"`
Copy link
Collaborator

Choose a reason for hiding this comment

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

What will happen if enabled is false? In other words, how to handle external etcd for example?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Updated.

// Default is not set.
// +optional
Resources corev1.ResourceRequirements `json:"resources,omitempty"`
}
Copy link
Collaborator

@xliuqq xliuqq Nov 20, 2023

Choose a reason for hiding this comment

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

Does Vineyard Fuse need NodeSelector and CleanPolicy field like other runtimes? These fields are used at GetRuntimeInfo method in the runtime.go file.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I think the answer is no, as the vineyard fuse only mounts the vineyard socket from hostpath to the application pod's PVC, so it must be co-located with application Pod. Adding a new nodeselector may mix the deployment of Vineyard Fuse. As for CleanPolicy, the only strategy is OnDemand. When the application pod is deleted, the fuse pod will be deleted after that. What do you think? @xliuqq

Copy link
Collaborator

Choose a reason for hiding this comment

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

@dashanji As far as I know,fuse is always co-located with application pod because the CSI plugin sets the node label fluid.io/f-{namespace}-{name} (fuse daemonset node selector expression), the nodeselector defines their(fuse/app) placement requirements.
The proposal says it supports RPC between app pod and vineyard pod, so we can use nodeselector to place the fuse/app pod with requirements ?
As for CleanPolicy, do you mean vineyard fuse not support OnRuntimeDeletedCleanPolicy ?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The #3528 says it supports RPC between app pod and vineyard pod. So we can use nodeselector to place the fuse/app pod with requirements?

I think the original nodeselector fluid.io/f-{namespace}-{name} is enough. If the app pod uses the RPC, we don't need the vineyard fuse (which mainly mounts vineyard socket from the hostpath) at all.

As for CleanPolicy, do you mean vineyard fuse not support OnRuntimeDeletedCleanPolicy?

Sorry for the mistake. I have checked the NodeStageVolume. Both OnDemand and OnRuntimeDeleted are supported, and the difference is whether the fuse pod still exists after the app pod is deleted. Maybe OnRuntimeDeletedCleanPolicy is more better.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@xliuqq Thanks for the advice. I have added the OnRuntimeDeletedCleanPolicy.
Maybe we could add nodeselector after the users make a request.

type MasterSpec struct {
// The component configurations for Vineyard Master
// +optional
VineyardCompTemplateSpec `json:",inline"`
Copy link
Collaborator

Choose a reason for hiding this comment

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

How about using endpoint for external uri?

endpoint:
      uri: "etcd-svc.etcd-namespace.svc.cluster.local:2379"
      encryptOptions:
        - name: access-key
          valueFrom:
            secretKeyRef:
              name: jfs-secret
              key: accesskey
        - name: secret-key
          valueFrom:
            secretKeyRef:
              name: jfs-secret
              key: secretkey

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Good point. In this way, we can check the status of the external etcd cluster.

// E,g. "etcd-svc.etcd-namespace.svc.cluster.local:2379"
// Default is not set and use http protocol to connect to external etcd cluster
// +optional
URI string `json:"uri"`
Copy link
Collaborator

Choose a reason for hiding this comment

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

Do we also need add options?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thanks for reminding, we have an option /prefix to define the prefix of etcd key for vineyard object.

// valueFrom:
// secretKeyRef:
// name: etcd-secret
// key: accesskey
//
// +optional
Enabled bool `json:"enabled,omitempty"`
Copy link
Collaborator

Choose a reason for hiding this comment

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

I think there is no need for Enabled?Right?

@dashanji
Copy link
Contributor Author

Hi @cheyang @xliuqq @TrafalgarZZZ Could you please approve the workflow? Thanks.


// Fuse holds the configurations for Vineyard Fuse
// +optional
Fuse VineyardFuseSpec `json:"fuse,omitempty"`
Copy link
Member

Choose a reason for hiding this comment

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

@dashanji Would it be better to use something like VineyardSockSpec or VineyardClientSpec instead of VineyardFuseSpec? From my understanding, we are not going to use the real vineyard fuse but using the vineyard socket to mimic a fake fuse.

So what I'm thinking is we can keep the VineyardRuntime.spec.fuse for API consistency with other runtimes. But in Fluid's codebase, we can avoid using Fuse as the golang struct's name. For example, something like:

// Fuse holds the configurations for Vineyard client socket.
// Note that  the "Fuse" here is kept just for API consistency, VineyardRuntime mount a socket file instead of a FUSE filesystem to make data cache available.
// <Maybe some Vineyard arch document here>
Fuse VineyardSockSpec `json:"fuse,omitempty"`

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Make sense to me. Thanks @TrafalgarZZZ

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Hi @TrafalgarZZZ. Could you please take another look?

Copy link
Member

Choose a reason for hiding this comment

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

@dashanji Sorry for responding late. Thanks! The PR LGTM.

Copy link

sonarcloud bot commented Nov 23, 2023

Kudos, SonarCloud Quality Gate passed!    Quality Gate passed

Bug A 0 Bugs
Vulnerability A 0 Vulnerabilities
Security Hotspot A 0 Security Hotspots
Code Smell A 14 Code Smells

No Coverage information No Coverage information
6.9% 6.9% Duplication

Copy link
Member

@TrafalgarZZZ TrafalgarZZZ left a comment

Choose a reason for hiding this comment

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

/lgtm

Copy link
Collaborator

@cheyang cheyang left a comment

Choose a reason for hiding this comment

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

/lgtm
/approve

Copy link

fluid-e2e-bot bot commented Nov 24, 2023

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: cheyang, xliuqq

The full list of commands accepted by this bot can be found here.

The pull request process is described 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

@fluid-e2e-bot fluid-e2e-bot bot merged commit 1e547fe into fluid-cloudnative:master Nov 24, 2023
11 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants