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

[schories]

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]

@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]

@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]

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

[dataclouder]

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]

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]

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