Anas Khan
0bf6f84ff5
retrieveMultisiteZone is meant to gate the object-store reconcile on the backing Ceph zone existing: it runs "radosgw-admin zone get" and, when that fails, returns a non-nil error so the caller requeues. That gate is dead code. The ENOENT check declares an inner err from exec.ExtractExitCode that shadows the outer command error, and ExtractExitCode returns a nil error for the ordinary exit failures radosgw-admin produces. Both the ENOENT branch and the else branch then wrap that shadowed nil, and errors.Wrapf(nil, ...) is nil, so the function returns (waitForRequeueIfObjectStoreNotReady, nil). The caller only propagates the requeue when the error is non-nil, so the requeue is dropped and reconcile runs on. The result is that a failed "zone get" no longer backs off. Reconcile proceeds to stand up the object store anyway -- the RGW service, the admin-ops endpoint, the deployment, and the pools radosgw scaffolds as it comes up -- for a multisite store whose backing zone does not exist. This is not the "normal multisite bootstrap" transient the original wording suggested. getMultisiteResourceNames runs immediately before this and already requeues until the CephObjectZone CR reports Ready, and the zone controller marks it Ready only after it has created the Ceph zone, so a healthy bootstrap never reaches this gate with a missing zone. That CR-Ready gate, not this one, is what actually blocks bootstrap. Where the dead gate does bite is the cases the CR status cannot cover: - the Ceph zone deleted or renamed out of band while the CR still reads Ready - a zone controller that reports Ready without leaving a usable zone behind - any non-ENOENT "zone get" failure, e.g. a permission or connectivity error, which the else branch swallows the same way The check was correct whenfc579f4520introduced it in 2020 with exec.ExitStatus, which returns (code, ok) and leaves err unshadowed.bd58790c31("ceph: proxy ceph commands when multus is configured", 2021) swapped it to exec.ExtractExitCode as an unrelated drive-by, inverting the contract and killing the gate. The sibling realm, zonegroup, and zone controllers were left untouched and still use exec.ExitStatus today. Restore exec.ExitStatus so the outer error is no longer shadowed, both branches wrap the real command error, and the caller requeues until the zone exists -- matching the sibling controllers. Signed-off-by: Anas Khan <83116240+anxkhn@users.noreply.github.com> Signed-off-by: Joshua Hoblitt <josh@hoblitt.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
- Events: Join community events on the public calendar
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-lfx.platform.linuxfoundation.org/meeting/91717550604?password=00364872-d5f3-440e-9c59-eca74d04ca51
- 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.
