Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Post VMs with their desired 'Running' state #437

Closed
ahadas opened this issue Jul 13, 2023 · 0 comments · Fixed by #633
Closed

Post VMs with their desired 'Running' state #437

ahadas opened this issue Jul 13, 2023 · 0 comments · Fixed by #633
Assignees
@ahadas
Milestone
2.6.0

Comments

@ahadas
Copy link
Member

ahadas commented Jul 13, 2023 

          ok, so not getting the vm is significant because we return an error but if we get the vm in down state while it's up then the implication is that we trigger a call to update the vm - that's insignificant

it would be better though to post the VM with the desired 'Running' state instead now that we post the VM at the end of the migration process

Originally posted by @ahadas in #432 (review)
@bennyz bennyz mentioned this issue Aug 2, 2023
Merged
@ahadas ahadas added this to the 2.6.0 milestone Oct 26, 2023
ahadas added a commit to ahadas/forklift that referenced this issue Oct 29, 2023
@ahadas
fix kubev2v#437: Post VMs with desired 'Running' state
afc4170 
Long time ago, we posted VMs at the beginning of the migration and then
started and stopped them during the migration and therefore in order to
restore their original power state, we had to initiate another call to
patch the VM with its desired power state.

However, now that we post the VMs at the very last steps of the
migration, we can set their desired power state in their specification
and avoid another call to the target environment.

Signed-off-by: Arik Hadas <ahadas@redhat.com>
@ahadas ahadas self-assigned this Oct 29, 2023
@ahadas ahadas linked a pull request Oct 29, 2023 that will close this issue
fix #437: Post VMs with desired 'Running' state #633
Merged
ahadas added a commit to ahadas/forklift that referenced this issue Oct 29, 2023
@ahadas
fix kubev2v#437: Post VMs with desired 'Running' state
9ea0e41 
Long time ago, we posted VMs at the beginning of the migration and then
started and stopped them during the migration and therefore in order to
restore their original power state, we had to initiate another call to
patch the VM with its desired power state.

However, now that we post the VMs at the very last steps of the
migration, we can set their desired power state in their specification
and avoid another call to the target environment.

Signed-off-by: Arik Hadas <ahadas@redhat.com>
ahadas added a commit that referenced this issue Oct 29, 2023
@ahadas
fix #437: Post VMs with desired 'Running' state
17c778e 
Long time ago, we posted VMs at the beginning of the migration and then
started and stopped them during the migration and therefore in order to
restore their original power state, we had to initiate another call to
patch the VM with its desired power state.

However, now that we post the VMs at the very last steps of the
migration, we can set their desired power state in their specification
and avoid another call to the target environment.

Signed-off-by: Arik Hadas <ahadas@redhat.com>
@ahadas ahadas reopened this Oct 30, 2023
@ahadas ahadas closed this as completed Oct 30, 2023
@ahadas ahadas changed the title Post the VM with the desired 'Running' state Post the VM with its desired 'Running' state Nov 2, 2023
@ahadas ahadas changed the title Post the VM with its desired 'Running' state Post VMs with their desired 'Running' state Nov 2, 2023
ahadas added a commit to ahadas/forklift that referenced this issue Nov 7, 2023
@ahadas
fix kubev2v#437: Post VMs with desired 'Running' state
3c1f121 
Long time ago, we posted VMs at the beginning of the migration and then
started and stopped them during the migration and therefore in order to
restore their original power state, we had to initiate another call to
patch the VM with its desired power state.

However, now that we post the VMs at the very last steps of the
migration, we can set their desired power state in their specification
and avoid another call to the target environment.

Signed-off-by: Arik Hadas <ahadas@redhat.com>
ahadas added a commit that referenced this issue Nov 7, 2023
@ahadas
fix #437: Post VMs with desired 'Running' state
1cbea2e 
Long time ago, we posted VMs at the beginning of the migration and then
started and stopped them during the migration and therefore in order to
restore their original power state, we had to initiate another call to
patch the VM with its desired power state.

However, now that we post the VMs at the very last steps of the
migration, we can set their desired power state in their specification
and avoid another call to the target environment.

Signed-off-by: Arik Hadas <ahadas@redhat.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@ahadas ahadas

Labels
None yet
Projects
None yet
Milestone
2.6.0
Development

Successfully merging a pull request may close this issue.

fix #437: Post VMs with desired 'Running' state ahadas/forklift
1 participant
@ahadas