Description of problem: "No method signature found" is returned when trying to export a VM to an export domain when specifying the storage domain by its name. Version-Release number of selected component (if applicable): 4.2 How reproducible: 100% Steps to Reproduce: 1. Invoke export VM via REST-API when the storage domain is specified by its name: vm_service.export( exclusive=True, discard_snapshots=True, storage_domain=types.StorageDomain( name='export' ) ) 2. 3. Actual results: The operation fails because the signature of export-to-export-domain's signature is not matched. Expected results: The export-to-export-domain method should be invoked. Additional info: The generated code seems to ignore the possibility of specifying a storage domain by its name [1] but relying on getting the ID of the storage domain in the signature lookup: /** * to_export_domain */ if (action!=null && action.getStorageDomain()!=null && action.getStorageDomain().getId()!=null ) { return VmResource.class.getMethod("exportToExportDomain", Action.class); } [1] https://github.com/oVirt/ovirt-engine-api-model/blob/master/src/main/java/services/VmService.java#L249
Does it happen when using the API? Or only thorough the SDK?
(In reply to Oved Ourfali from comment #1) > Does it happen when using the API? Or only thorough the SDK? I reproduced it with the SDK but the code I quoted in comment 1 resides in the engine so I expect it to fail also when using the API.
A possible workaround is to specify the storage domain using its ID: vm_service.export( exclusive=True, discard_snapshots=True, storage_domain=types.StorageDomain( id='413b6ece-3c2a-4c17-855f-a1d2c66c67b3' ) )
We are working on a fix, however it is not that simple. Do we want it to block 4.2.0 GA? There is a workaround, working by ID.
(In reply to Oved Ourfali from comment #4) > We are working on a fix, however it is not that simple. > Do we want it to block 4.2.0 GA? > There is a workaround, working by ID. Indeed, it's not a blocker. I'm more concerned that it's a regression, btw.
(In reply to Yaniv Kaul from comment #5) > (In reply to Oved Ourfali from comment #4) > > We are working on a fix, however it is not that simple. > > Do we want it to block 4.2.0 GA? > > There is a workaround, working by ID. > > Indeed, it's not a blocker. I'm more concerned that it's a regression, btw. We know where it comes from. We're just trying to find a good solution, which might not be immediate.
This problem is fixed in version 1.2.16 of the API metamodel. That version has been already released. The problem will be completely fixed when the engine is updated to use the new version of the model. I think we can re-target for 4.2.0, if there will be another build of 4.2.0.
*** Bug 1524302 has been marked as a duplicate of this bug. ***
export with storage name in RESTAPI worked fine (also tested in sdk-java 3.6.10 and sdk-python 4.2.2 with success) verified in ovirt-engine-restapi-4.2.0.2-0.1.el7.noarch
This bugzilla is included in oVirt 4.2.0 release, published on Dec 20th 2017. Since the problem described in this bug report should be resolved in oVirt 4.2.0 release, published on Dec 20th 2017, it has been closed with a resolution of CURRENT RELEASE. If the solution does not work for you, please open a new bug report.