[WIP] Move dataset.spec.mounts length validation logic from the CRD definition down into the controller

[Syspretor]

With Fluid's expansion for flexible usage of datasets, it is now permitted for the length of the mounts array in a dataset to be zero in some Runtimes. For example, the recent version supports dynamic mounting capabilities and the dataset bound with Vinyard runtime only allowed zero length mountPoints.

However, the existing definition of the Dataset Custom Resource Definition (CRD) enforces a minimum length of 1 for the Dataset.spec.mounts field. This minimum length constraint in the CRD limits the flexibility of the dataset. As datasets are intended to be an abstract collection of data and designed as mutable APIs, the validation logic for the mounts field should not be uniformly restricted by the CRD. Instead, it should be up to the runtime level to determine whether and how to impose such restrictions.

Therefore, in this pull request, I propose removing the minNum constraint on dataset.spec.mounts in the CRD and delegating the validation of the length of dataset mounts to the implementation of the controller.

[fluid-e2e-bot[bot]]

[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 assign zwwhdls for approval by writing /assign @zwwhdls in a comment. 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:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment Approvers can cancel approval by writing /approve cancel in a comment

[sonarqubecloud[bot]]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud