feedc0de/my-rook-config
1
0 Fork 0
forked from rook/rook
Code Pull Requests Activity

Merge pull request #11290 from travisn/storage-provider-status

Browse Source 
docs: Clarify in docs and readme that Rook focuses on Ceph
This commit is contained in:
Travis Nielsen authored and GitHub committed 2022-11-14 14:41:37 -07:00
2 parents 0b3dd7fe13 b79d9022a4
commit 0e7791b6fc
4 files changed
+15 -121
Download Patch File Download Diff File Expand all files Collapse all files

No files matched your search

Documentation/Contributing/.pages
-1
View File
@@ -2,5 +2,4 @@ nav:
- development-flow.md
- development-environment.md
- documentation.md
- storage-providers.md
- ...
Documentation/Contributing/storage-providers.md
-93
View File
@@ -1,93 +0,0 @@
---
title: Storage Providers
---
Rook is the home for operators for multiple storage providers. Each of these storage providers
has specific requirements and each of them is very independent. There is no runtime dependency
between the storage providers. Development is where the storage providers benefit from one another.
Rook provides a development framework with a goal of enabling storage providers to create
operators for Kubernetes to manage their storage layer. As the storage provider community
grows, we expect this framework to grow as common storage constructs are identified
that will benefit the community. Rook does not aim to replace other frameworks or
communities, but to fill gaps not provided by other core projects.
Storage providers in Rook are currently built on the [Controller Runtime](https://github.com/kubernetes-sigs/controller-runtime),
but may also be built on other frameworks such as the [Operator SDK](https://sdk.operatorframework.io/)
or [Kubebuilder](https://github.com/kubernetes-sigs/kubebuilder). The choice of the
underlying framework is up to the storage provider.
Rook does not aim to be a general framework for storage, but to provide a
very specific set of helpers to meet the storage provider needs in the Rook project.
## Rook Framework
Rook provides the following framework to assist storage providers in building an operator:
* Common golang packages shared by storage providers are in the main [Rook repo](https://github.com/rook/rook).
* Common build scripts for building the operator images are in the main
[Rook repo](https://github.com/rook/rook/tree/master/build).
* Each provider has its own repo under the [Rook org](https://github.com/rook).
* Multiple community members are given push access to the repo, including
owners of the storage provider, Rook steering committee members,
and other Rook maintainers if deemed helpful or necessary by the steering
committee. Maintainers for the new provider are added according to the
[governance](https://github.com/rook/rook/blob/master/GOVERNANCE.md).
* Providers added to Rook prior to 2020 are grandfathered into the main
[Rook repo](https://github.com/rook/rook).
* Storage providers must follow the Rook [governance](https://github.com/rook/rook/blob/master/GOVERNANCE.md)
in the interest of the good of the overall project. Storage providers have
autonomy in their feature work, while collaboration with the community
is expected for shared features.
* A quarterly release cadence is in place for the operators in the main Rook repo.
Operators in their own repo define their own cadence and versioning scheme as desired.
* Storage providers own their release process, while following Rook best practices to
ensure high quality.
* Each provider owns independent CI based on GitHub actions, with patterns and build
automation that can be re-used by providers
* Docker images are pushed to the [Rook DockerHub](https://hub.docker.com/u/rook) where
each storage provider has its own repo.
* Helm charts are published to [charts.rook.io](https://charts.rook.io/release)
* Documentation for the storage provider is to be written by the storage provider
members. The build process will publish the documentation to the [Rook website](https://rook.io/docs/rook/latest/).
* All storage providers are added to the [Rook.io website](https://rook.io/)
* A great Slack community is available where you can communicate amongst developers and users
## Considering Joining Rook?
If you own a storage provider and are interested in joining the Rook project to create
an operator, please consider the following:
* You are making a clear commitment to the development of the storage provider.
Creating an operator is not a one-time engineering cost, but is a long term commitment
to the community.
* Support for a storage provider in Rook requires dedication and community support.
* Do you really need an operator? Many storage applications (e.g. CSI drivers)
can be deployed with tools such as a Helm chart and don't really need the
flexibility of an operator.
* Joining Rook is also about community, not just the framework.
## Engineering Requirements
The engineering costs of each storage provider include:
* Develop the operator
* Rook maintainers will help answer questions along the way, but ultimately
you own the development
* If there are test failures in the CI, they should be investigated in a timely manner
* If issues are opened in GitHub, they need investigation and triage to provide
expectations about the priority and timeline
* If users have questions in Slack, they should be answered in a timely manner.
Community members can also be redirected to other locations if desired for the provider.
* A regular cadence of releases is expected. Software always needs to evolve with new versions
of K8s, accommodate new features in the storage provider, etc.
* Each provider maintains a ROADMAP.md in the root of their repo, updates it regularly
(e.g. quarterly or with the release cadence), and provides input to the overall Rook
[roadmap](https://github.com/rook/rook/blob/master/ROADMAP.md) for common features.
### Inactive Providers
If a storage provider does not have engineering resources, Rook cannot claim to support it.
After some months of inactivity Rook will deprecate a storage provider. The timing
will be decided on a case by case basis by the steering committee. The repo and other artifacts
for deprecated storage providers will be left intact for reference.
Documentation/README.md
+7 -4
View File
@@ -4,13 +4,16 @@ title: Rook
# Rook
Rook is an open source **cloud-native storage orchestrator**, providing the platform, framework, and support for a diverse set of storage solutions to natively integrate with cloud-native environments.
Rook is an open source **cloud-native storage orchestrator**, providing the platform, framework, and support for
Ceph storage to natively integrate with cloud-native environments.
Rook turns storage software into self-managing, self-scaling, and self-healing storage services. It does this by automating deployment, bootstrapping, configuration, provisioning, scaling, upgrading, migration, disaster recovery, monitoring, and resource management. Rook uses the facilities provided by the underlying cloud-native container management, scheduling and orchestration platform to perform its duties.
[Ceph](https://ceph.com/) is a distributed storage system that provides file, block and object storage and is deployed in large scale production clusters.
Rook integrates deeply into cloud native environments leveraging extension points and providing a seamless experience for scheduling, lifecycle management, resource management, security, monitoring, and user experience.
Rook automates deployment and management of Ceph to provide self-managing, self-scaling, and self-healing storage services.
The Rook operator does this by building on Kubernetes resources to deploy, configure, provision, scale, upgrade, and monitor Ceph.
The Ceph operator was declared stable in December 2018 in the Rook v0.9 release, providing a production storage platform for several years already.
The Ceph operator was declared stable in December 2018 in the Rook v0.9 release, providing a production storage platform for many years.
Rook is hosted by the [Cloud Native Computing Foundation](https://cncf.io) (CNCF) as a [graduated](https://www.cncf.io/announcements/2020/10/07/cloud-native-computing-foundation-announces-rook-graduation/) level project.
## Quick Start Guide
README.md
+8 -23
View File
@@ -11,20 +11,20 @@
# What is Rook?
Rook is an open source **cloud-native storage orchestrator** for Kubernetes, providing the platform, framework, and support for a diverse set of storage solutions to natively integrate with cloud-native environments.
Rook is an open source **cloud-native storage orchestrator** for Kubernetes, providing the platform, framework, and support for Ceph storage to natively integrate with Kubernetes.
Rook turns storage software into self-managing, self-scaling, and self-healing storage services. It does this by automating deployment, bootstrapping, configuration, provisioning, scaling, upgrading, migration, disaster recovery, monitoring, and resource management. Rook uses the facilities provided by the underlying cloud-native container management, scheduling and orchestration platform to perform its duties.
[Ceph](https://ceph.com/) is a distributed storage system that provides file, block and object storage and is deployed in large scale production clusters.
Rook integrates deeply into cloud native environments leveraging extension points and providing a seamless experience for scheduling, lifecycle management, resource management, security, monitoring, and user experience.
Rook automates deployment and management of Ceph to provide self-managing, self-scaling, and self-healing storage services.
The Rook operator does this by building on Kubernetes resources to deploy, configure, provision, scale, upgrade, and monitor Ceph.
For more details about the storage solutions currently supported by Rook, please refer to the [project status section](#project-status) below.
We plan to continue adding support for other storage systems and environments based on community demand and engagement in future releases. See our [roadmap](ROADMAP.md) for more details.
The status of the Ceph storage provider is **Stable**. Features and improvements will be planned for many future versions. Upgrades between versions are provided to ensure backward compatibility between releases.
Rook is hosted by the [Cloud Native Computing Foundation](https://cncf.io) (CNCF) as a [graduated](https://www.cncf.io/announcements/2020/10/07/cloud-native-computing-foundation-announces-rook-graduation/) level project. If you are a company that wants to help shape the evolution of technologies that are container-packaged, dynamically-scheduled and microservices-oriented, consider joining the CNCF. For details about who's involved and how Rook plays a role, read the CNCF [announcement](https://www.cncf.io/blog/2018/01/29/cncf-host-rook-project-cloud-native-storage-capabilities).
## Getting Started and Documentation
For installation, deployment, and administration, see our [Documentation](https://rook.github.io/docs/rook/latest).
For installation, deployment, and administration, see our [Documentation](https://rook.github.io/docs/rook/latest-release) and [QuickStart Guide](https://rook.github.io/docs/rook/latest-release/Getting-Started/quickstart).
## Contributing
@@ -52,7 +52,7 @@ Please use the following to reach members of the community:
- Twitter: [@rook_io](https://twitter.com/rook_io)
- Security topics: [cncf-rook-security@lists.cncf.io](#reporting-security-vulnerabilities)
### Community Meeting
## Community Meeting
A regular community meeting takes place every other [Tuesday at 9:00 AM PT (Pacific Time)](https://zoom.us/j/392602367?pwd=NU1laFZhTWF4MFd6cnRoYzVwbUlSUT09).
Convert to your [local timezone](http://www.thetimezoneconverter.com/?t=9:00&tz=PT%20%28Pacific%20Time%29).
@@ -65,23 +65,8 @@ Anyone who wants to discuss the direction of the project, design and implementat
- [Current agenda and past meeting notes](https://docs.google.com/document/d/1exd8_IG6DkdvyA0eiTtL2z5K2Ra-y68VByUUgwP7I9A/edit?usp=sharing)
- [Past meeting recordings](https://www.youtube.com/playlist?list=PLP0uDo-ZFnQP6NAgJWAtR9jaRcgqyQKVy)
## Project Status
The status of each storage provider supported by Rook can be found in the table below.
Each API group is assigned its own individual status to reflect their varying maturity and stability.
More details about API versioning and status in Kubernetes can be found on the Kubernetes [API versioning page](https://kubernetes.io/docs/concepts/overview/kubernetes-api/#api-versioning), but the key difference between the statuses are summarized below:
- **Alpha:** The API may change in incompatible ways in a later software release without notice, recommended for use only in short-lived testing clusters, due to increased risk of bugs and lack of long-term support.
- **Beta:** Support for the overall features will not be dropped, though details may change. Support for upgrading or migrating between versions will be provided, either through automation or manual steps.
- **Stable:** Features will appear in released software for many subsequent versions and support for upgrading between versions will be provided with software automation in the vast majority of scenarios.
| Name | Details | API Group | Status |
| ---- | ---------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------- | ------ |
| Ceph | [Ceph](https://ceph.com/) is a distributed storage system that provides file, block and object storage and is deployed in large scale production clusters. | ceph.rook.io/v1 | Stable |
This repo is for the Ceph storage provider. The [Cassandra](https://github.com/rook/cassandra) and [NFS](https://github.com/rook/nfs) storage providers moved to a separate repo to allow for each [storage provider](https://rook.github.io/docs/rook/latest/storage-providers.html) to have an independent development and release schedule.
### Official Releases
## Official Releases
Official releases of Rook can be found on the [releases page](https://github.com/rook/rook/releases).
Please note that it is **strongly recommended** that you use [official releases](https://github.com/rook/rook/releases) of Rook, as unreleased versions from the master branch are subject to changes and incompatibilities that will not be supported in the official releases.