[Incubation] Fluid Incubation Application

[RongGu]

Fluid Incubation Application

Project Repo(s): https://github.com/fluid-cloudnative
Project Site: https://fluid-cloudnative.github.io/
Sub-Projects: N/A
Communication: #fluid on CNCF Slack

Project points of contacts：

• Rong Gu (gurong @ nju.edu.cn)
• Yang Che (cheyang52 @ gmail.com)

Incubation Criteria Summary for Fluid

Adoption Assertion

The project has been adopted by the following organizations in a testing and integration or production capacity:
See ADOPTERS.

Application Process Principles

Suggested

N/A

Required

• Give a presentation and engage with the domain specific TAG(s) to increase awareness

It was completed and occurred on 10-07-2024, and can be discovered at LINK.

• TAG provides insight/recommendation of the project in the context of the landscape

To be completed by TAG Storage.

• All project metadata and resources are vendor-neutral.

Fluid was jointly initiated by multiple organizations including Nanjing Univeristy, Alibaba Cloud, and Alluxio, now has transferred ownership to the CNCF, and set the CNCF as an owner on the following infrastructure, communication channels, and project resources as part of Sandbox acceptance.

Fluid implements the open and vendor neutral governance model where the key decisions are made via open conversation and consensus in the Fluid community channels (GitHub, Dingding Group, Wechat Group and Slack).

• Review and acknowledgement of expectations for Sandbox projects and requirements for moving forward through the CNCF Maturity levels.

Met during sandbox onboarding
Yes. We have understood the expectations for sandbox projects and requirements for moving forward through the CNCF incubation level. We believe Fluid have met the requirements.

• Due Diligence Review.

To be done by TOC.
We have completed the Due Diligence Review of Fluid. Please the check link.

• Additional documentation as appropriate for project type, e.g.: installation documentation, end user documentation, reference implementation and/or code samples.

Yes. We have added the required documentation as follows.
Installation documentation is available at https://fluid-cloudnative.github.io/docs/next/get-started/installation.
User documentation is available at https://fluid-cloudnative.github.io/docs/next.
Architecture documentation is at https://fluid-cloudnative.github.io/docs/next/core-concepts/architecture-and-concepts.

Governance and Maintainers

Note: this section may be augmented by the completion of a Governance Review from TAG Contributor Strategy.

Suggested

• Clear and discoverable project governance documentation.

Governance documentation is here: https://github.com/fluid-cloudnative/fluid/blob/master/GOVERNANCE.md

• Governance has continuously been iterated upon by the project as a result of their experience applying it, with the governance history demonstrating evolution of maturity alongside the project's maturity evolution.

Yes. Initial maintainers were from Fluid primarily. We have independent maintainers and few other contributors who are shaping up to take the ownership of the modules. KubeArmor now has 7 Maintainers from 4 organizations and 17 Committers from 14 organizations.
Please check the link

Governance is up to date and Fluid project has been running bi-weekly community meeting for 3 years now. Fluid also regularly promote contributors with the established voting and approval process. Check here

• Governance is up to date with actual project activities, including any meetings, elections, leadership, or approval processes.

Yes. See the election according governance rule here.

• Governance clearly documents vendor-neutrality of project direction.
  Yes.

• Document how the project makes decisions on leadership, contribution acceptance, requests to the CNCF, and changes to governance or project goals.

Yes. It is in a section in our governance rule here . In addition, the project decisions are discussed in open issues and we use vote process to make the final decision. For example: Agree to accept New Committers.

• Document how role, function-based members, or sub-teams are assigned, onboarded, and removed for specific teams (example: Security Response Committee).

Fluid uses the GitHub team to manage the roles and remembers, for example fluid-security team responses to the security issues.

• Document a complete maintainer lifecycle process (including roles, onboarding, offboarding, and emeritus status).

Yes. See the election according governance rule here .

• Demonstrate usage of the maintainer lifecycle with outcomes, either through the addition or replacement of maintainers as project events have required.

Updates to the Fluid OWNER file, example PR

• If the project has subprojects: subproject leadership, contribution, maturity status documented, including add/remove process.

N/A.

Required

• Document complete list of current maintainers, including names, contact information, domain of responsibility, and affiliation.

The list of current maintainers is here: https://github.com/fluid-cloudnative/fluid/blob/master/MAINTAINERS_COMMITTERS.md

• A number of active maintainers which is appropriate to the size and scope of the project.

7 active maintainers from Nanjing University, Alibaba, Alluxio, JuiceData and China Telecom.

• Code and Doc ownership in Github and elsewhere matches documented governance roles.

Contributor Guide

• Document agreement that project will adopt CNCF Code of Conduct.

Code of conduct

• CNCF Code of Conduct is cross-linked from other governance documents.

It is the link.

• All subprojects, if any, are listed.

N/A

Contributors and Community

Note: this section may be augmented by the completion of a Governance Review from TAG Contributor Strategy.

Suggested

• Contributor ladder with multiple roles for contributors.

Contributor promotion process

Required

• Clearly defined and discoverable process to submit issues or changes.

Fluid Contribution Guide

• Project must have, and document, at least one public communications channel for users and/or contributors.

Fluid communication channels

• List and document all project communication channels, including subprojects (mail list/slack/etc.). List any non-public communications channels and what their special purpose is.

CNCF slack channels: #fluid
WeChat Group: Fluid Open Source Group
Dingding Group: Fluid Open Source Group

• Up-to-date public meeting schedulers and/or integration with CNCF calendar.

• Documentation of how to contribute, with increasing detail as the project matures.

• Demonstrate contributor activity and recruitment.

GitHub Stars: 200 => 1600+
GitHub Forks: 20 => 700+
Number of Contributors: 80 => 500+
Contributing member organizations: 12 => 30+
Number of Commits: 700 => 2400+
Healthy Committers: 7 maintainers from 5 organizations, 17 committers from 14 organizations
Specific devStats can be found at:
https://fluid.devstats.cncf.io/d/5/companies-table?orgId=1&var-period_name=Since%20joining%20CNCF&var-metric=contributions.

Engineering Principles

Suggested

• Roadmap change process is documented.

Example Roadmap Update

• History of regular, quality releases.

Flud currently follows quarterly release, see the release tag history

Fluid project goals and objectives

Required

• Document project goals and objectives that illustrate the project’s differentiation in the Cloud Native landscape as well as outlines how this project fulfills an outstanding need and/or solves a problem differently.

Fluid project goals and objectives

• Document what the project does, and why it does it - including viable cloud native use cases.

Fluid what and why

• Document and maintain a public roadmap or other forward looking planning document or tracking mechanism.

Example Roadmap

• Document overview of project architecture and software design that demonstrates viable cloud native use cases, as part of the project's documentation.

architecture and software design

• Document the project's release process.

Release Process

Security

Note: this section may be augemented by a joint-assessment performed by TAG Security.

Suggested

N/A

Required

• Clearly defined and discoverable process to report security issues.

Security issue reporting process
Security Contacts

• Enforcing Access Control Rules to secure the code base against attacks (Example: two factor authentication enforcement, and/or use of ACL tools.)

• Document assignment of security response roles and how reports are handled.

https://github.com/fluid-cloudnative/fluid/blob/master/SECURITY.md
Security scanning is enabled for the project and fluid-security is responsible for fixing the vulnerability issues.

• Document Security Self-Assessment.
  Yes. It is here

• Achieve the Open Source Security Foundation (OpenSSF) Best Practices passing badge.

OpenSSF Best Practices passing badge

Ecosystem

Suggested

N/A

Required

• Publicly documented list of adopters, which may indicate their adoption level (dev/trialing, prod, etc.)

Adopters are tracked here https://github.com/fluid-cloudnative/fluid/blob/master/ADOPTERS.md

• Used in appropriate capacity by at least 3 independent + indirect/direct adopters, (these are not required to be in the publicly documented list of adopters)

The project can provide the TOC with a list of adopters for verification of use of the project at the level expected, i.e. production use for graduation, dev/test for incubation.

• TOC verification of adopters.

Refer to the Adoption portion of this document.

• Clearly documented integrations and/or compatibility with other CNCF projects as well as non-CNCF projects.

• Helm is used to deploy Fluid’s control plane to Kubernetes.
• Vineyard is one kind of Fluid runtime, which is used to share distributed data in various big data tasks. Here is the reference.
• Kserve can use Fluid to accelerate large language model loading. Here is the reference.
• KubeDL uses Fluid as the cache engine to improve the data access speed of datasets which can reduce the time spent in training and increase the utilization rate of GPU and the efficiency of model training. Here is the reference.
• CubeFS makes for a very powerful combination with Fluid to provide dataset management, data access acceleration and enhance observability along with resource management. Here is the reference.
• Knative can use Fluid to accelerate data access with sidecar mode which can avoid CSI plugin installation. Here is the reference.
• Open Cluster Management can use Fluid to accelerate data access to multiple managed K8s clusters. Here is the reference and demo.
• Prometheus to collect and analyze both system and user level metrics. Here is the reference.

Additional Information

[kevin-wangzefeng]

@RongGu could you please finish the application checklist? It's a prerequisite before this application is picked up by a TOC member. Also, please:

• review the definition of an adopter
• verify 5-7 project adopters that can and are willing to be interviewed by the TOC reviewer(s) and
  submit information for each adopter to the Adopter Interview Questionnaire form

[RongGu]

Dear @kevin-wangzefeng, thank you for reminding us about our application case! Over the past few days, we have completed most of the action items on the checklist.

Regarding the Due Diligence Review item, this step needs to be completed by the TOC.
We have completed the Due Diligence Review of Fluid. Please the check link link for more details.

We are also in the process of reaching out to our project adopters who are able and willing to be interviewed by the TOC reviewers. Once we have completed the information for each adopter in the Adopter Interview Questionnaire form, I will notify you. Thank you!

[angellk]

Confirmed adopters have been added - moving Fluid project to 'Ready for assignment'. As a TOC member is available, they will self-assign and reach out for next steps @RongGu

[RongGu]

Got it. Thank you @angellk @kevin-wangzefeng !