-
Notifications
You must be signed in to change notification settings - Fork 961
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
Add the vineyard runtime CRD definitions. #3555
Conversation
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 Once the patch is verified, the new status will be reflected by the 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. |
Codecov ReportAll modified and coverable lines are covered by tests ✅
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. |
// Resources contains the resource requirements and limits for the Vineyard Master. | ||
// Default is not set. | ||
// +optional | ||
Resources corev1.ResourceRequirements `json:"resources,omitempty"` |
There was a problem hiding this comment.
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
.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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"` |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Make sense to me.
@dashanji please fix github action/lint by running 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 |
@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"` |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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"` | ||
} |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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
?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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"` |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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"` |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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"` |
There was a problem hiding this comment.
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?
dc48f04
to
2321579
Compare
Hi @cheyang @xliuqq @TrafalgarZZZ Could you please approve the workflow? Thanks. |
|
||
// Fuse holds the configurations for Vineyard Fuse | ||
// +optional | ||
Fuse VineyardFuseSpec `json:"fuse,omitempty"` |
There was a problem hiding this comment.
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"`
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
Signed-off-by: Ye Cao <[email protected]>
5148cc6
to
46bb89b
Compare
Kudos, SonarCloud Quality Gate passed! 0 Bugs No Coverage information |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/lgtm
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/lgtm
/approve
[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 |
Ⅰ. Describe what this PR does
Add the vineyard runtime CRD definitions.
Ⅱ. Does this pull request fix one issue?
Fixes parts of #3528