New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
docs: add guide doc for flex migration #9222
Conversation
this is at top of #9221 |
edac328
to
4c6d328
Compare
2b4da81
to
e6c3a7d
Compare
c63a260
to
b8292dc
Compare
a4b5567
to
38305fe
Compare
4. Create the CSI storage class to which you want to migrate | ||
5. Create migrator pod | ||
1) `kubectl create -f <update this with file link in the tool repo>` | ||
6. Download the tool binary |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was thinking about an approach to build an image that includes the binary, and no need for this manual step to get it... In the 1.7 branch, we add an image to the build that is just like the rook ceph image, but it also includes the tool binary. Then the sample migrator.yaml would just pull that image. The image on dockerhub would appear as rook/flex-migration:v1.7.9
, where the tag would be the latest 1.7.x release. Rooks existing release process should make this fairly simple to implement.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
With that approach it makes sense to include the migrator.yaml in the rook repo as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The latest discussion is that we can just add the tool to the main rook image in the 1.7 releases. No need to create a new image.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
do we still need migrator.yaml file in rook?
a23c524
to
6022b0c
Compare
|
||
## Migration Tool Options | ||
|
||
These are the options for converting a single PVC. **For more options**, see the [tool documentation](https://github.com/ceph/persistent-volume-migrator), for example to convert all PVCs automatically that belong to the same storage class. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These are the options for converting a single PVC. **For more options**, see the [tool documentation](https://github.com/ceph/persistent-volume-migrator), for example to convert all PVCs automatically that belong to the same storage class. | |
These are the options for converting a single PVC. For more options, see the [tool documentation](https://github.com/ceph/persistent-volume-migrator), for example to convert all PVCs automatically that belong to the same storage class. |
Why was this bold?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The thought was to get more eyes but yeah we can remove them too.
2ce58ae
to
7aaaed3
Compare
7aaaed3
to
3deeb79
Compare
3deeb79
to
b809a7c
Compare
This pull request has merge conflicts that must be resolved before it can be merged. @subhamkrai please rebase it. https://rook.io/docs/rook/latest/development-flow.html#updating-your-fork |
b809a7c
to
3deeb79
Compare
This pull request has merge conflicts that must be resolved before it can be merged. @subhamkrai please rebase it. https://rook.io/docs/rook/latest/development-flow.html#updating-your-fork |
Hi @subhamkrai, this pull request was opened against a release branch, is it expected? Normally patches should go in the master branch first and then be backported to release branches. |
3deeb79
to
a9cda1e
Compare
I tried to move this PR from master to release-1.7 branch...messed in between but looks good now 😄 |
Yes, this is intentional. |
4917b7b
to
5e81b88
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My test of the conversion worked! just a few small suggestions in the doc...
My test consisted of creating flex volumes for mysql and wordpress example app pods, then converting them with these commands:
kubectl scale --replicas=0 deploy/wordpress-mysql
kubectl scale --replicas=0 deploy/wordpress
# connect to the migrator pod
pv-migrator --pvc=mysql-pv-claim --pvc-ns=default --destination-sc=rook-ceph-block-csi
pv-migrator --pvc=wp-pv-claim --pvc-ns=default --destination-sc=rook-ceph-block-csi
# disconnect from the migrator pod
kubectl scale --replicas=1 deploy/wordpress-mysql
kubectl scale --replicas=1 deploy/wordpress
I1125 07:56:26.504578 63 log.go:34] waiting for PV pvc-30a01887-8821-4baf-835c-16a7e55ba7f0 in state &PersistentVolumeStatus{Phase:Bound,Message:,Reason:,} to be deleted (0 seconds elapsed) | ||
I1125 07:56:26.702921 63 log.go:34] deleted persistent volume pvc-30a01887-8821-4baf-835c-16a7e55ba7f0 | ||
I1125 07:56:26.702944 63 log.go:34] successfully migrated pvc rbd-pvc | ||
I1125 07:56:26.703335 63 log.go:34] Successfully migrated all the PVCs to CSI |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If only one PVC is being migrated, the tool should skip printing this line, it was confusing.
I1125 07:56:26.703335 63 log.go:34] Successfully migrated all the PVCs to CSI |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this I'll need to change in tool side first. will open PR
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We need to log something after successful migration. How about this
Successfully migrated flex PVCs to CSI
Migration done successfully
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The message for individual PVC names seems sufficient. Or instead of saying "all" PVCs, how about printing the number of PVCs converted?
Good to know it is working as expected! |
5e81b88
to
f2f9f58
Compare
Adding guide doc for migrating rbd flexvolume to ceph-csi. Signed-off-by: subhamkrai <srai@redhat.com>
Missed few nits of flex-migrator,doing it here as discussed. Signed-off-by: subhamkrai <srai@redhat.com>
f2f9f58
to
bd55c7e
Compare
I1125 07:56:26.504578 63 log.go:34] waiting for PV pvc-30a01887-8821-4baf-835c-16a7e55ba7f0 in state &PersistentVolumeStatus{Phase:Bound,Message:,Reason:,} to be deleted (0 seconds elapsed) | ||
I1125 07:56:26.702921 63 log.go:34] deleted persistent volume pvc-30a01887-8821-4baf-835c-16a7e55ba7f0 | ||
I1125 07:56:26.702944 63 log.go:34] successfully migrated pvc rbd-pvc | ||
I1125 07:56:26.703335 63 log.go:34] Successfully migrated all the PVCs to CSI |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The message for individual PVC names seems sufficient. Or instead of saying "all" PVCs, how about printing the number of PVCs converted?
Description of your changes:
Adding guide doc for migrating rbd flexvolume to ceph-csi.
Which issue is resolved by this Pull Request:
Resolves #
Checklist:
make codegen
) has been run to update object specifications, if necessary.