ee8bcad49d
For the specification see: <https://github.com/rook/rook/blob/master/design/ceph/object/swift-and-keystone-integration.md> * extend the API object specs for swift and keystone integration * adapt rgw to the new go-ceph version - The parameter lists of the API call have changes, as parameters ignored by the RGW Admin Ops API are no longer serialized, therefore the mock has to be adapted. - There is now validation for the user keys that are passed to the User get API, therefore things failed when we had empty keys in our User proxy object. * expand the reconcile loop for the swift and keystone integration * fix minor mistakes in design document * add env var to pass extra args to minikube Minikube decides CPU cores and memory automatically based on the available resources on the machine which may be insufficient to run rook. This commit adds an environment variable to add arbitrary arguments to the minikube command, so both can be specified if desired. * integration tests for swift and keystone The new integration of swift or s3 and keystone support by rook does not have any integration tests yet. This commit introduces integration tests for swift and keystone. The tests are done against a minimal keystone setup (keystone container image from Yaook-project (https://yaook.cloud), sqlite as database backend, cert-manager and trust-manager for test certificate setup). To prevent hardcoded credentials, passwords are generated by the tests. The integration tests use the openstack client (keystone- and swift-functionality) (https://docs.openstack.org/ python-openstackclient/ latest/). This was a concious design decision to use client tooling as close as possible to the end user instead of using other go-libraries (such as gophercloud). * add documentation on swift and keystone Currently there is no documentation on the use of Swift to access an object store as well as the use of OpenStack keystone for authentication. This commit adds documentation on the use of Swift and OpenStack keystone, as well as CRD-related documentation and an example setup. * add integration tests for S3 via keystone This commit introduces integration tests for s3 and keystone. The tests are run against the same minimal keystone setup that the tests for swift and keystone use. The integration tests use the aws s3 client to use client tooling as close as possible to the end user instead of using other go-libraries. Co-authored-by: Jan Klippel <jan.klippel@uhurutec.com> Co-authored-by: Silvio Ankermann <silvio.ankermann@cloudandheat.com> Signed-off-by: Sebastian Riese <sebastian.riese@cloudandheat.com> Signed-off-by: Jan Klippel <jan.klippel@uhurutec.com> Signed-off-by: Silvio Ankermann <silvio.ankermann@cloudandheat.com>
What is Rook?
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.
Ceph is a distributed storage system that provides file, block and object storage and is deployed in large scale production clusters.
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 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 (CNCF) as a graduated 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.
Getting Started and Documentation
For installation, deployment, and administration, see our Documentation and QuickStart Guide.
Contributing
We welcome contributions. See Contributing to get started.
Report a Bug
For filing bugs, suggesting improvements, or requesting new features, please open an issue.
Reporting Security Vulnerabilities
If you find a vulnerability or a potential vulnerability in Rook please let us know immediately at cncf-rook-security@lists.cncf.io. We'll send a confirmation email to acknowledge your report, and we'll send an additional email when we've identified the issues positively or negatively.
For further details, please see the complete security release process.
Contact
Please use the following to reach members of the community:
- Slack: Join our slack channel
- GitHub: Start a discussion or open an issue
- Twitter: @rook_io
- Security topics: cncf-rook-security@lists.cncf.io
Community Meeting
A regular community meeting takes place the 2nd Tuesday of every month at 9:00 AM PT (Pacific Time). Convert to your local timezone.
Any changes to the meeting schedule will be added to the agenda doc and posted to Slack #announcements.
Anyone who wants to discuss the direction of the project, design and implementation reviews, or general questions with the broader community is welcome and encouraged to join.
- Meeting link: https://zoom.us/j/98052644520?pwd=K0R4RUZCc3NhQisyMnA5VlV2MVBhQT09
- Current agenda and past meeting notes
- Past meeting recordings
Official Releases
Official releases of Rook can be found on the releases page. Please note that it is strongly recommended that you use official 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. Builds from the master branch can have functionality changed and even removed at any time without compatibility support and without prior notice.
Licensing
Rook is under the Apache 2.0 license.
