Qin, Does this change require a change in the downstream documentation? Is ther something users must do as a result of it? If so, please explain the change. Thank you.
Jeff, Does this change require a change in the downstream documentation? Is there something users must do as a result of it? If so, please explain the change. Thank you.
(In reply to Richard Hoch from comment #1) > Qin, > > Does this change require a change in the downstream documentation? Is ther > something users must do as a result of it? If so, please explain the change. > Thank you. In the 'Source virtual machine prerequisites' section, see https://access.redhat.com/documentation/en-us/migration_toolkit_for_virtualization/2.3/html/installing_and_using_the_migration_toolkit_for_virtualization/prerequisites#source-vm-prerequisites_mtv, it is claimed that the source VM name must fulfill certain requirements. Previously, users have to change the source VM name if it's non-conformant, otherwise the VM can't be migrated. With the fix of bug 1959883, the non-conformant source VM name won't block the migration, it will be automatically adjusted to a target name that is compliant with RFC 1123.
(In reply to Richard Hoch from comment #3) > Jeff, > > Does this change require a change in the downstream documentation? Is there > something users must do as a result of it? If so, please explain the change. > Thank you. with the current implementation, the VM renaming happens automatically and a warning message is presented to the users during the create plan stage, no user interference is required. Because of that, I don't think there's something that needs to be added to the documentation.
Qin and Bella, If I understand correctly: * If we leave the documentaion as is, users who read and follow instructions will create VM names that do not need to be changed later. * If we remove the prerequisites, if a user creates a bad name, the name will be changes and the user will be told (and given the new name, right?) in a warning message. Warning messages are frustrating so I suggest leaving the prerequisites in the document -- that is, make no change. Bella -- that follows your recommendation. Qin -- what do you think?
(In reply to Richard Hoch from comment #6) > Qin and Bella, > > If I understand correctly: > * If we leave the documentaion as is, users who read and follow > instructions will create VM names that do not need to be changed later. > * If we remove the prerequisites, if a user creates a bad name, the name > will be changes and the user will be told (and given the new name, right?) > in a warning message. > > Warning messages are frustrating so I suggest leaving the prerequisites in > the document -- that is, make no change. > > Bella -- that follows your recommendation. Qin -- what do you think? How about adding a note telling users that if a VM name is not compliant with the requirements, it can be automatically adjusted. Users could have a choice to change the name on source Env before migration, or let the migration process to automatically rename it on target Env. If there are lots of VMs to be migrated, users have to scan all the VMs names to make sure they are valid, maybe they will need to develop a script to do such task. I think it makes sense to tell users that the migration tool itself has the auto renaming functionality, it's up to users to use it or not. If we don't mention the feature, users must follow the requirements strictly, there won't be any VM name exception, then what's the meaning of implementing the auto renaming feature?
(In reply to Qin Yuan from comment #7) > (In reply to Richard Hoch from comment #6) > > Qin and Bella, > > > > If I understand correctly: > > * If we leave the documentaion as is, users who read and follow > > instructions will create VM names that do not need to be changed later. > > * If we remove the prerequisites, if a user creates a bad name, the name > > will be changes and the user will be told (and given the new name, right?) > > in a warning message. > > > > Warning messages are frustrating so I suggest leaving the prerequisites in > > the document -- that is, make no change. > > > > Bella -- that follows your recommendation. Qin -- what do you think? > > How about adding a note telling users that if a VM name is not compliant > with the requirements, it can be automatically adjusted. Users could have a > choice to change the name on source Env before migration, or let the > migration process to automatically rename it on target Env. > If there are lots of VMs to be migrated, users have to scan all the VMs > names to make sure they are valid, maybe they will need to develop a script > to do such task. I think it makes sense to tell users that the migration > tool itself has the auto renaming functionality, it's up to users to use it > or not. > If we don't mention the feature, users must follow the requirements > strictly, there won't be any VM name exception, then what's the meaning of > implementing the auto renaming feature? Right its a good point, so regarding the documentation, I think we can remove this from the requirements since it no longer blocks the migration and adds it as a note, specifying the required compatibility and the auto renaming option, and also maybe worth mentioning the newly generated names that will be picked so the users will have the option to choose between the auto renaming or manual renaming of the VMs before the migration themselves if it's less suitable for there needs.
(In reply to Qin Yuan from comment #7) > How about adding a note telling users that if a VM name is not compliant > with the requirements, it can be automatically adjusted. Users could have a > choice to change the name on source Env before migration, or let the > migration process to automatically rename it on target Env. > If there are lots of VMs to be migrated, users have to scan all the VMs > names to make sure they are valid, maybe they will need to develop a script > to do such task. I think it makes sense to tell users that the migration > tool itself has the auto renaming functionality, it's up to users to use it > or not. > If we don't mention the feature, users must follow the requirements > strictly, there won't be any VM name exception, then what's the meaning of > implementing the auto renaming feature? +1 to that and to comment 8 Renaming VMs on the source is still an option of course but it may mean that the VM needs to be restarted before the migration, and that's another step users need to do which complicates the entire migration, especially on scale. This feature was requested to simplify and improve that, I wouldn't 'hide' it in the documentation
Arik, Bella, and Xin, Please review this PR: https://github.com/kubev2v/forklift-documentation/pull/344
I approved on github and added Bella as a reviewer (didn't find Qin, I'll follow up with her)
Looking good, but I think it's worth mentioning what will be the newly generated name. I've added a comment on github with the info.
Bella, Good idea -- made the change you suggested. Please review the PR again: https://github.com/kubev2v/forklift-documentation/pull/344
(In reply to Richard Hoch from comment #13) > Bella, > > Good idea -- made the change you suggested. Please review the PR again: > https://github.com/kubev2v/forklift-documentation/pull/344 Looking good, just approved in github. Thanks!
Arik, Does this still need QE?
Yes and usually Meital should assign it but as Qin tested the feature and approved the doc change, assigning to Qin
Qin, please review https://github.com/kubev2v/forklift-documentation/pull/344. Arik and Bela approved it.
(In reply to Richard Hoch from comment #17) > Qin, please review > https://github.com/kubev2v/forklift-documentation/pull/344. Arik and Bela > approved it. Hi Richard, I commented on a small typo, please check.
Qin, Fixed it, thanks. Please check again. https://github.com/kubev2v/forklift-documentation/pull/344
(In reply to Richard Hoch from comment #19) > Qin, > > Fixed it, thanks. Please check again. > https://github.com/kubev2v/forklift-documentation/pull/344 Approved, move this bug to VERIFIED.
PR merged and published.