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

doc: update release notes and upgrade docs

Browse Source 
Update pending release notes and upgrade docs for v1.17.

Signed-off-by: Blaine Gardner <blaine.gardner@ibm.com>
This commit is contained in:
Blaine Gardner committed 2025-04-07 09:57:20 -06:00
1 parent 1f787d77cc
commit deb9838324
2 files changed
+45 -35
Download Patch File Download Diff File Expand all files Collapse all files

No files matched your search

Documentation/Upgrade/rook-upgrade.md
+38 -30
View File
@@ -14,7 +14,7 @@ We welcome feedback and opening issues!
## Supported Versions
This guide is for upgrading from **Rook v1.15.x to Rook v1.16.x**.
This guide is for upgrading from **Rook v1.16.x to Rook v1.17.x**.
Please refer to the upgrade guides from previous releases for supported upgrade paths.
Rook upgrades are only supported between official releases.
@@ -22,6 +22,7 @@ Rook upgrades are only supported between official releases.
For a guide to upgrade previous versions of Rook, please refer to the version of documentation for
those releases.
* [Upgrade 1.15 to 1.16](https://rook.io/docs/rook/v1.16/Upgrade/rook-upgrade/)
* [Upgrade 1.14 to 1.15](https://rook.io/docs/rook/v1.15/Upgrade/rook-upgrade/)
* [Upgrade 1.13 to 1.14](https://rook.io/docs/rook/v1.14/Upgrade/rook-upgrade/)
* [Upgrade 1.12 to 1.13](https://rook.io/docs/rook/v1.13/Upgrade/rook-upgrade/)
@@ -50,18 +51,25 @@ those releases.
official releases. Builds from the master branch can have functionality changed or removed at any
time without compatibility support and without prior notice.
## Breaking changes in v1.16
## Breaking changes in v1.17
* The minimum supported Kubernetes version is v1.27.
* The minimum supported Kubernetes version is v1.28.
* Rook no longer supports Ceph v17 (Quincy) as it is end of life. Rook v1.15 clusters should
[upgrade Ceph](./ceph-upgrade.md) to at least Ceph v18 (Reef) before upgrading Rook to v1.16.
Be aware of known [Ceph v18.2.4 ARM issues](https://github.com/rook/rook/issues/14502).
* S3 users provisioned via CephObjectStoreUser resources no longer allow multiple credentials to
exist on underlying S3 users, unless explicitly managed by Rook. Rook will purge all but one of
the undeclared credentials. This could be a user observable regression for administrators who
manually edited/rotated S3 user credentials for CephObjectStoreUsers. For affected users, Rook
now provides first-class
[user credential management support](../Storage-Configuration/Object-Storage-RGW/object-storage.md#managing-user-s3-credentials).
For more details, see [#15359](https://github.com/rook/rook/issues/15359).
* Rook fully deprecated CSI "holder" pods in Rook v1.16. Any Rook v1.15 CephCluster with
`csi-*plugin-holder-*` pods present in the Rook operator namespace must follow holder pod
removal migration steps outlined in
[v1.15 documentation](https://rook.io/docs/rook/v1.15/CRDs/Cluster/network-providers/?h=depre#holder-pod-deprecation).
* Some ObjectBucketClaim options were added in Rook v1.16 that allowed more control over buckets.
These controls allow users to self-serve their own S3 policies, which many administrators might
consider a risk, depending on their environment. Rook has taken steps to ensure potentially risky
configurations are disabled by default to ensure the safest off-the-shelf configurations.
Administrators who wish to allow users to use the full range of OBC configurations must use the
new `ROOK_OBC_ALLOW_ADDITIONAL_CONFIG_FIELDS` to enable users to set potentially risky options.
See [#15376](https://github.com/rook/rook/pull/15376) for more information.
## Considerations
@@ -77,11 +85,11 @@ With this upgrade guide, there are a few notes to consider:
Unless otherwise noted due to extenuating requirements, upgrades from one patch release of Rook to
another are as simple as updating the common resources and the image of the Rook operator. For
example, when Rook v1.16.1 is released, the process of updating from v1.16.0 is as simple as running
example, when Rook v1.17.1 is released, the process of updating from v1.17.0 is as simple as running
the following:
```console
git clone --single-branch --depth=1 --branch v1.16.1 https://github.com/rook/rook.git
git clone --single-branch --depth=1 --branch v1.17.1 https://github.com/rook/rook.git
cd rook/deploy/examples
```
@@ -89,11 +97,11 @@ If the Rook Operator or CephCluster are deployed into a different namespace than
`rook-ceph`, see the [Update common resources and CRDs](#1-update-common-resources-and-crds)
section for instructions on how to change the default namespaces in `common.yaml`.
Then, apply the latest changes from v1.16, and update the Rook Operator image.
Then, apply the latest changes from v1.17, and update the Rook Operator image.
```console
kubectl apply -f common.yaml -f crds.yaml
kubectl -n rook-ceph set image deploy/rook-ceph-operator rook-ceph-operator=rook/ceph:v1.16.1
kubectl -n rook-ceph set image deploy/rook-ceph-operator rook-ceph-operator=rook/ceph:v1.17.1
```
As exemplified above, it is a good practice to update Rook common resources from the example
@@ -127,9 +135,9 @@ In order to successfully upgrade a Rook cluster, the following prerequisites mus
## Rook Operator Upgrade
The examples given in this guide upgrade a live Rook cluster running `v1.15.6` to
the version `v1.16.0`. This upgrade should work from any official patch release of Rook v1.15 to any
official patch release of v1.16.
The examples given in this guide upgrade a live Rook cluster running `v1.16.6` to
the version `v1.17.0`. This upgrade should work from any official patch release of Rook v1.16 to any
official patch release of v1.17.
Let's get started!
@@ -190,7 +198,7 @@ kubectl apply -f deploy/examples/monitoring/rbac.yaml
!!! hint
The operator is automatically updated when using Helm charts.
The largest portion of the upgrade is triggered when the operator's image is updated to `v1.16.x`.
The largest portion of the upgrade is triggered when the operator's image is updated to `v1.17.x`.
When the operator is updated, it will proceed to update all of the Ceph daemons.
```console
@@ -221,18 +229,18 @@ watch --exec kubectl -n $ROOK_CLUSTER_NAMESPACE get deployments -l rook_cluster=
```
As an example, this cluster is midway through updating the OSDs. When all deployments report `1/1/1`
availability and `rook-version=v1.16.0`, the Ceph cluster's core components are fully updated.
availability and `rook-version=v1.17.0`, the Ceph cluster's core components are fully updated.
```console
Every 2.0s: kubectl -n rook-ceph get deployment -o j...
rook-ceph-mgr-a req/upd/avl: 1/1/1 rook-version=v1.16.0
rook-ceph-mon-a req/upd/avl: 1/1/1 rook-version=v1.16.0
rook-ceph-mon-b req/upd/avl: 1/1/1 rook-version=v1.16.0
rook-ceph-mon-c req/upd/avl: 1/1/1 rook-version=v1.16.0
rook-ceph-osd-0 req/upd/avl: 1// rook-version=v1.16.0
rook-ceph-osd-1 req/upd/avl: 1/1/1 rook-version=v1.15.6
rook-ceph-osd-2 req/upd/avl: 1/1/1 rook-version=v1.15.6
rook-ceph-mgr-a req/upd/avl: 1/1/1 rook-version=v1.17.0
rook-ceph-mon-a req/upd/avl: 1/1/1 rook-version=v1.17.0
rook-ceph-mon-b req/upd/avl: 1/1/1 rook-version=v1.17.0
rook-ceph-mon-c req/upd/avl: 1/1/1 rook-version=v1.17.0
rook-ceph-osd-0 req/upd/avl: 1// rook-version=v1.17.0
rook-ceph-osd-1 req/upd/avl: 1/1/1 rook-version=v1.16.6
rook-ceph-osd-2 req/upd/avl: 1/1/1 rook-version=v1.16.6
```
An easy check to see if the upgrade is totally finished is to check that there is only one
@@ -241,14 +249,14 @@ An easy check to see if the upgrade is totally finished is to check that there i
```console
# kubectl -n $ROOK_CLUSTER_NAMESPACE get deployment -l rook_cluster=$ROOK_CLUSTER_NAMESPACE -o jsonpath='{range .items[*]}{"rook-version="}{.metadata.labels.rook-version}{"\n"}{end}' | sort | uniq
This cluster is not yet finished:
rook-version=v1.15.6
rook-version=v1.16.0
rook-version=v1.16.6
rook-version=v1.17.0
This cluster is finished:
rook-version=v1.16.0
rook-version=v1.17.0
```
### **5. Verify the updated cluster**
At this point, the Rook operator should be running version `rook/ceph:v1.16.0`.
At this point, the Rook operator should be running version `rook/ceph:v1.17.0`.
Verify the CephCluster health using the [health verification doc](health-verification.md).
PendingReleaseNotes.md
+7 -5
View File
@@ -12,11 +12,13 @@ Object:
new `ROOK_OBC_ALLOW_ADDITIONAL_CONFIG_FIELDS` to enable users to set potentially risky options.
See https://github.com/rook/rook/pull/15376 for more information.
- Add credentials/keys management to CephObjectStoreUser. Note that this will
cause manually created credentials/keys on an rgw user to be purged. This
behavior is necessary to ensure that keys that were explicitly declared and
then undeclared are purged. This could be a user observable regression.
(see [#15359](https://github.com/rook/rook/issues/15359)
- Add first-class credential management to CephObjectStoreUser. Existing S3 users provisioned via
CephObjectStoreUser resources no longer allow multiple credentials to exist on underlying S3
users, unless explicitly managed by Rook. Rook will purge all but one of the undeclared
credentials. This could be a user observable regression for administrators who manually
edited/rotated S3 user credentials for CephObjectStoreUsers. Affected users should make use of
the new credential management feature instead.
For more details, see [#15359](https://github.com/rook/rook/issues/15359).
## Features