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.

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

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
wants to merge 1 commit into from

Conversation

schories
Copy link

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 #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
Copy link
Member

@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
Copy link
Member

@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
Copy link
Member

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

@dataclouder
Copy link
Contributor

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
Copy link
Author

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
Copy link
Contributor

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

@dataclouder dataclouder removed the request for review from adezxc March 8, 2024 11:43
@schories schories closed this by deleting the head repository May 29, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Option eject_force do not eject media without an human intervention
3 participants