-
Notifications
You must be signed in to change notification settings - Fork 233
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
Update volume migration doc #840
base: main
Are you sure you want to change the base?
Conversation
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
/hold |
Signed-off-by: Alice Frosi <[email protected]>
e17ebbe
to
c2ab988
Compare
/lgtm |
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.
Thanks for adding this information! I just have a couple of grammar nits but otherwise it looks good.
docs/storage/volume_migration.md
Outdated
The users could, for various reasons, wish to stop and cancel the ongoing volume migration. | ||
Migration cancellations are also handled declaratively, thus users must restore the previous set of volumes, which will be read as a cancellation for the volume update and migration. | ||
|
||
A possible way to cancel the migration consists apply the old version of the VM declaration. |
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.
A possible way to cancel the migration is to apply the old version of the VM declaration.
docs/storage/volume_migration.md
Outdated
|
||
If for any reasons the VMI disappears, then the volume migration isn't retried anymore. This might happen if the users inadvertently shutdown the VM or the VMI is accidentally deleted. | ||
|
||
However, in these situations, the VM spec is in an inconsistent state because the volume set contains the destination volumes but the copy wasn't successful, and users could fail to boot correctly the VM. For this reason the VM is marked with the condition `ManualRecoveryRequired` and KubeVirt will refuses to start a VM which has this condition. |
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.
will refuse
/lgtm |
@duyanyan: changing LGTM is restricted to collaborators In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
Pull requests that are marked with After that period the bot marks them with the label /label needs-approver-review |
Signed-off-by: Alice Frosi <[email protected]>
c2ab988
to
36d0415
Compare
/unhold |
/lgtm |
@duyanyan: changing LGTM is restricted to collaborators In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
/lgtm |
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.
Great stuff. I have a couple of little changes.
Two additional things:
- major: it looks as though Document update volume strategy and volume migration #805 did not add an
volume_migration.md
to theuser-guide/docs/storage/.pages
file, so it is not visible in the TOC. We may as well add it in this PR. - minor: You can change the 'the user' to 'you can' etc to make the sentences active. We have both in the docs so it's not a big deal but active is better and more commonly used throughout the user guide.
(An exception would be if the doc is targeted to an admin, who is performing tasks for their users.)
|
||
In order to recover the VM spec, the users need to revert the volume set in the VM spec as it is the case for the volume migration cancellation. | ||
|
||
The volume migration information is stored in the VM status as well, and the users can see the full list of the migrated volumes which contain the source and destination names as well as the corresponding volume name . |
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 volume migration information is stored in the VM status as well, and the users can see the full list of the migrated volumes which contain the source and destination names as well as the corresponding volume name . | |
The volume migration information is stored in the VM status as well, and the users can see the full list of the migrated volumes which contain the source and destination names as well as the corresponding volume name. |
|
||
### Manual recovery required | ||
|
||
If for any reasons the VMI disappears, then the volume migration isn't retried anymore. This might happen if the users inadvertently shutdown the VM or the VMI is accidentally deleted. |
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 for any reasons the VMI disappears, then the volume migration isn't retried anymore. This might happen if the users inadvertently shutdown the VM or the VMI is accidentally deleted. | |
If for any reasons the VMI disappears, then the volume migration is not retried anymore. This might happen if the users inadvertently shutdown the VM or the VMI is accidentally deleted. |
As a general rule we should avoid contractions in documentation.
|
||
If for any reasons the VMI disappears, then the volume migration isn't retried anymore. This might happen if the users inadvertently shutdown the VM or the VMI is accidentally deleted. | ||
|
||
However, in these situations, the VM spec is in an inconsistent state because the volume set contains the destination volumes but the copy wasn't successful, and users could fail to boot correctly the VM. For this reason the VM is marked with the condition `ManualRecoveryRequired` and KubeVirt will refuse to start a VM which has this condition. |
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.
However, in these situations, the VM spec is in an inconsistent state because the volume set contains the destination volumes but the copy wasn't successful, and users could fail to boot correctly the VM. For this reason the VM is marked with the condition `ManualRecoveryRequired` and KubeVirt will refuse to start a VM which has this condition. | |
However, in these situations, the VM spec is in an inconsistent state because the volume set contains the destination volumes but the copy was not successful, and users could fail to boot correctly the VM. For this reason the VM is marked with the condition `ManualRecoveryRequired` and KubeVirt will refuse to start a VM which has this condition. |
What this PR does / why we need it:
Update the volume migration with the information about the volume migration cancellation and recovery. Additionally, it also fix the title of the document
Release note: