add "expectingAction" status to make sure - in case of a locked media - the vmquestion is recognized and can be "forcefully" automatically answered again.

vmware / go-vcloud-director

Golang SDK for VMware Cloud Director

Other

80 stars 79 forks source link

add "expectingAction" status to make sure - in case of a locked media - the vmquestion is recognized and can be "forcefully" automatically answered again. #620

Closed schories closed 2 months ago

schories commented 10 months ago

IMPORTANT

Issue

Simple fix for 1 additional, missing status - causing the automatic answering of vmquestions - which arise in case of "locked" media in vm - and therefore the media eject task to fail.

Very likely also fixes https://github.com/vmware/go-vcloud-director/issues/552

Description

The "expectingAction" status is also missing from official "task type - status" documentation: https://developer.vmware.com/apis/1260/doc/types/TaskType.html

Yet, it represents the status of an media eject task

in case of a locked virtual drive
therefore while the vm is waiting for the vmquestion to be answered (by human or WaitTaskCompletion function), whether media shall be forcefully removed anyway

This PR

adds the "expectingAction" status
to make sure - in case of a locked media - the vmquestion is recognized and can be "forcefully" automatically answered again.

vmwclabot commented 10 months ago

@schories, you must sign our contributor license agreement before your changes are merged. Click here to sign the agreement. If you are a VMware employee, read this for further instruction.

vmwclabot commented 10 months ago

@schories, we have received your signed contributor license agreement. The review is usually completed within a week, but may take longer under certain circumstances. Another comment will be added to the pull request to notify you when the merge can proceed.

vmwclabot commented 10 months ago

@schories, VMware has approved your signed contributor license agreement.

dataclouder commented 10 months ago

Hi @schories Thanks for this contribution. While the change is small enough, we are always looking to avoid side effects in other operations. Before accepting it, we will run the full test suite to see whether something else breaks. Still, the ideal contribution should include a test that demonstrates the need for such a change. The best solution would be for you to provide a test that reproduces the case. I understand that this is a lot to ask for a one-line change. If you are unable to do so, please at least provide a code snippet that reproduces the issue.

schories commented 10 months ago

Hi,

after reading https://github.com/vmware/go-vcloud-director/blob/main/TESTING.md I understood that a VCD is required, to run the existing tests.

For ejecttask.go currently no ejecttask_test.go is existing. So I would start building those test from scratch - but:

My customer is a tenant of a commercial VCD offering. The tenant VCD access is production level. Obviously I won't run the test suite against that VCD.

What options, besides buying/renting a VCD instance myself on a hyperscaler, do I have?

While I can support to a certain degree and would appreciate releasing additions and fixes to the public, I obviously won't spent serious money on top of that.

Thanks,

Alexander

dataclouder commented 10 months ago

@schories if you can make a test, we will run it and eventually suggest changes.