-
Notifications
You must be signed in to change notification settings - Fork 75
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
BUSY_ENTITY -> Java Exception #616
Comments
Hi, Thanks for submitting this issue. The described behaviour is not really a bug. The API entities/resources like the As a reference, here is the way we created a retry function for testing, maybe you could utilise it in your process: https://github.com/vmware/go-vcloud-director/blob/main/govcd/api_vcd_test.go#L2037-L2054 |
Hi, i completely agree with you that it isn't a "bug" and that resources should NOT be changed at the same time by different applications. But it can happen and i think every application should handle it. So maybe "enhancement" is a better label ;-) As i already wrote: From my point of view the error message "400" is totaly wrong. Because its not a client error (Except that it sent the request to the wrong time). 503 would fit much better here. |
SDK only provides an interface to the VCD API and is not in control of its responses, it is our intent to make it as accurate as possible and we wouldn't want to change that. While with Terraform, even though it could be possible to have these checks, again, we would need to re-think all of our resources if there are any concurrent operations happening outside of Terraform, which undermines the (probably) biggest benefit of using the tool of having somewhat stable state that one can expect to be true. The bottom line is: we shouldn't try to convert into concurrent an operation that was designed to be serialized in VCD. |
Describe the bug
Hello,
we are a german MSP and offers Cloud Director Services to our customer.
As an MSP "extra service" we add some data (OrgVDC Name etc) to each VMs guestinfo.* variables via an API call.
This is working fine and the customers loves these information about the cloud infrastructure in there VM.
The issue is, that update of the guestinfo.* variables locks the VM for a few seconds.
And here is the issue:
Some customers deploy their VMs with terraform-provider of vCD and they randomly report errors:
If the VM is locked by our "guestinfo update process" and terroform tries to do something with the VM they receive an
The entity Ref: com.vmware.vcloud.entity.vm:740ea4a2-6904-4bdd-b97d-9a0ecc8e79d9 is busy completing an operation VAPP_UPDATE_VM. VAPP_UPDATE_VM(com.vmware.vcloud.entity.task:4eefa495-c6ed-4f0f-8ff0-fd98d8ac05a1)" majorErrorCode="400" minorErrorCode="BUSY_ENTITY"/>
Besides the main issue that an error code 400 is wrong (because it's not an client error) (503 or 429 is more appropiate)
is it possible to add a retries in the case of "BUSY ENTITY" to the vCD sdk?
Kind Regards,
Marcel
Reproduction steps
Expected behavior
If "BUSY ENTITY" is received, wait a few seconds and try again instead throw an exception
Additional context
Complete Log
The text was updated successfully, but these errors were encountered: