[Graduation] Dragonfly Graduation Application #1358

gaius-qi · 2024-06-26T16:07:29Z

Dragonfly Graduation Application

Project Repo(s): https://github.com/dragonflyoss/Dragonfly2, https://github.com/dragonflyoss/Dragonfly and other repos under https://github.com/dragonflyoss.
Project Site: https://d7y.io/
Sub-Projects: nydus, nydus-snapshotter, api, console, monitoring, client.
Communication: Slack, Meetings, Mailing List([email protected]), DingTalk(23304666).

Project points of contacts:

Maintainers Mailing List: [email protected]
#dragonfly channel on CNCF Slack

Graduation Criteria Summary for Dragonfly

Adoption Assertion

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

Criteria

Application Process Principles

Suggested

N/A

Required

Give a presentation and engage with the domain specific TAG(s) to increase awareness
- Tag Runtime: Dragonfly presentation (Graduation).

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

All project metadata and resources are vendor-neutral.

Review and acknowledgement of expectations for graduated projects and requirements for moving forward through the CNCF Maturity levels.
- Met during Project's application on 31-Aug-2023 (in our initial PR Dragonfly Graduation Proposal #1161 )

Completion of this due diligence document, resolution of concerns raised, and presented for public comment satisifies the Due Diligence Review criteria.

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

Governance and Maintainers

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

Suggested

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.

Dragonfly joined the CNCF as a sandbox project in October 2018 and became an incubating project in April 2020. In January 2020, Nydus became a sub-project of Dragonfly and was widely used for image acceleration. In April 2021, the Dragonfly v2.0 was released after architectural optimization and code refactoring. Dragonfly has 12 maintainers (committers). The public list of Dragonfly adopters is in the ADOPTERS.md. We've looked to expand our governance.

Required

Clear and discoverable project governance documentation.

https://github.com/dragonflyoss/Dragonfly2/blob/main/GOVERNANCE.md

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

We sync information in the mailing list([email protected]) in time.

Governance clearly documents vendor-neutrality of project direction.

Most of our decisions today are made by maintainers who're actively involved in the project, and we've set out a clear path for people to become maintainers. We have maintainers spread across several companies and we'd gladly accept more.

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

This is included in our governance docs and in our contributor docs.

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

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

All maintainers share all domains of responsbility currently, refer to maintainers.

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

Dragonfly has 12 maintainers (committers) from
Alibaba Group, Ant Group, Baidu Group, Dalian University of Technology, ByteDance, Intel and JiHu.

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

https://github.com/dragonflyoss/Dragonfly2/blob/main/GOVERNANCE.md

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

We've moved a couple of maintainers to emeritus status as they've drifted away from the project. This lists current and emeritus maintainers, refer to OWNERS.md.

Project maintainers from at least 2 organizations that demonstrates survivability.

There are 12 maintainers from 7 different companies.

Code and Doc ownership in Github and elsewhere matches documented governance roles.
This is documented in the governance process for maintainers. GitHub Teams for Maintainers and Reveivers are managed for each repo.

Document agreement that project will adopt CNCF Code of Conduct.
We operate under the CNCF CoC.

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

The Contributing is in the https://github.com/dragonflyoss/Dragonfly2/blob/main/CONTRIBUTING.md#contributing-to-dragonfly.

All subprojects, if any, are listed.

All the subproject are list in the repos.

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

Mentioned at the beginning of our governance docs:

This doc outlines the responsibilities of contributor roles in Dragonfly. The Dragonfly project is subdivided into sub-projects under (predominantly, but not exclusively) nydus, nydus-snapshotter, api, docs, console and client. Responsibilities for roles are scoped to these sub-projects (repos).

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.

Documented in https://github.com/dragonflyoss/Dragonfly2/blob/main/GOVERNANCE.md.

Required

Clearly defined and discoverable process to submit issues or changes.

Documented in https://github.com/dragonflyoss/Dragonfly2/blob/main/CONTRIBUTING.md.

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

We have several, listed at the top of this issue.

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.

All listed here.

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

Public Dragonfly community meetings are listed in the CNCF calendar. Tracing in the community.

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

Documented in https://github.com/dragonflyoss/Dragonfly2/blob/main/CONTRIBUTING.md.

Demonstrate contributor activity and recruitment.
We would like to thank teams who have made outstanding contributions, such as https://github.com/dragonflyoss/Dragonfly2/releases/tag/v2.0.9.

Engineering Principles

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.

Landing Page in d7y.io:

Provide efficient, stable, secure file distribution and image acceleration based on p2p technology to be the best practice and standard solution in cloud native architectures.

Now Dragonfly is not only used in image acceleration, but also has many use cases in file distribution and AI model distribution.

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

Documented in https://d7y.io/docs/next/.

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

See the Roadmap list. We will update it once a year.

Roadmap change process is documented.

Documented in https://github.com/dragonflyoss/community/blob/master/ROADMAP.md.

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

Documented in https://d7y.io/docs/next/.

Document the project's release process and guidelines publicly in a RELEASES.md or equivalent file that defines:
- Release expectations (scheduled or based on feature implementation)
- Tagging as stable, unstable, and security related releases
- Information on branch and tag strategies
- Branch and platform support and length of support
- Artifacts included in the release.
- Additional information on topics such as LTS and edge releases are optional. Release expectations are a social contract between the project and its end users and hence changes to these should be well thought out, discussed, socialized and as necessary agreed upon by project leadership before getting rolled out.

Documented in https://github.com/dragonflyoss/community/blob/master/RELEASE.md.

History of regular, quality releases.

Dragonfly publishs the release in https://github.com/dragonflyoss/Dragonfly2/releases. And we will release to the cncf blogs, refer to https://www.cncf.io/blog/2023/08/07/dragonfly-v2-1-0-is-released/.

Security

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

Suggested

Achieving OpenSSF Best Practices silver or gold badge.

We'll look into this down the road but it's not an immediate priority for us.

Required

Clearly defined and discoverable process to report security issues.

SECURITY.md stores in the repo.

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

2FA required for GitHub org members.

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

Documented in Security Policy.

Document Security Self-Assessment.

Documented in Security Self-Assessment. We intend to merge the PR to TAG Security repository.

Third Party Security Review.
- Moderate and low findings from the Third Party Security Review are planned/tracked for resolution as well as overall thematic findings, such as: improving project contribution guide providing a PR review guide to look for memory leaks and other vulnerabilities the project may be susceptible to by design or language choice ensuring adequate test coverage on all PRs.

A third party security audit was performed by Trail of Bits, you can see the full report here.

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

https://www.bestpractices.dev/zh-CN/projects/7103

Ecosystem

Suggested

N/A

Required

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

This list shows non-exhaustive adopters of dragonfly.

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)

We have more than 3 adopters, and with the rapid development of the AI ecosystem, Dragonfly is also being used as a model distribution service by more AI companies.

The project provided 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.

Dragonfly integrates with many CNCF projects:

harbor preheats image by dragonfly.
containerd distributes image by dragonfly.
cri-o distributes image by dragonfly.
prometheus to collect metrics.
artifacthub saves Dragonfly charts.
gRPC for high-performance remote procedure calls (RPC).
Helm used to deploy Dragonfly to Kubernetes.