Open MarcelMertens opened 11 months ago
Hi,
Thanks for submitting this issue.
The described behaviour is not really a bug. The API entities/resources like the vm
are not intended to be managed by different applications at the same time. (e.g Terraform and UI) One would need to implement such checks himself as otherwise it would convolute the SDK and it would become much harder to keep track of the state of an entity.
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. While a retry mechanism is not suitable for the SDK, your client applications can attempt dealing with that to handle concurrent usage from different applications.
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