Failed to import ova about vsphere-connect HOT 18 OPEN

@bhoriuchi About the attributes:

in v1 @nagavenkatab code returns the importSpecParams with xsi:type attribute, however no such attribute is returned in v2

from vsphere-connect.

by debugging more I see that configSpec is missing in the spec params of ImportVApp method, not sure is it causing the issue

from vsphere-connect.

I think i see the issue. You are attempting to create new objects with types from vim which is not currently implemented. See code https://github.com/bhoriuchi/soap-connect/blob/development/src/client/types.js#L47-L51 So you are essentially getting back an empty object that only has the fields you are setting on it. I can look into this further and try to implement it as i think it was already on my todo list.

Until then you will need to fully build the specs with javascript objects and it is best to include the type as documented here https://github.com/bhoriuchi/soap-connect/blob/development/src/client/types.js#L47-L51 since the soap library does a best match on the types if the type is not explicitly defined which can lead to incorrect types.

from vsphere-connect.

I can add more info on this issue:

In version 1.1.1 of this package we used to get the attributes returned by the vCenter and that is missing in v2 because of which, when we chain the response of createImportSpec Params to ImportVapp we see an err

from vsphere-connect.

@DrigerG which attributes are those? Also this is definitely because the package now uses a custom soap library instead of node-soap which i found to be problematic and slow due do no wsdl caching features. I'd like to get the code you are running to reproduce as well if you wouldnt mind commenting here or opening another issue.

from vsphere-connect.

I was able to work around the issue by doing the below steps to the returned importSpec:

    delete response.importSpec.instantiationOst
    response.importSpec.instantiationOst.id = ''
    delete response.importSpec.instantiationOst.section;
    delete response.importSpec.instantiationOst.child[0].section;
    delete response.importSpec.instantiationOst.child[0].child;
    response.importSpec['@xsi:type'] = 'vim25:VirtualMachineImportSpec'
    response.importSpec.configSpec.deviceChange[0].device['@xsi:type'] = 'vim25:VirtualCdrom'
    response.importSpec.configSpec.deviceChange[0].device.backing['@xsi:type'] = 'vim25:VirtualCdromRemotePassthroughBackingInfo'
    response.importSpec.configSpec.deviceChange[1].device['@xsi:type'] = 'vim25:VirtualDisk'
    response.importSpec.configSpec.deviceChange[1].device.backing['@xsi:type'] = 'vim25:VirtualDiskFlatVer2BackingInfo'
    response.importSpec.configSpec.deviceChange[1].device.backing['fileName'] = ''
    response.importSpec.configSpec.deviceChange[2].device['@xsi:type'] = 'vim25:VirtualIDEController'
    response.importSpec.configSpec.deviceChange[3].device['@xsi:type'] = 'vim25:VirtualIDEController'
    response.importSpec.configSpec.deviceChange[5].device['@xsi:type'] = 'vim25:VirtualLsiLogicController'
    response.importSpec.configSpec.deviceChange[6].device['@xsi:type'] = 'vim25:VirtualMachineVMCIDevice'
    response.importSpec.configSpec.deviceChange[7].device['@xsi:type'] = 'vim25:VirtualE1000'
    response.importSpec.configSpec.deviceChange[7].device.backing['@xsi:type'] = 'vim25:VirtualEthernetCardNetworkBackingInfo'
    delete response.importSpec.configSpec.cpuFeatureMask;
    delete response.importSpec.configSpec.extraConfig;
    delete response.importSpec.configSpec.vAppConfig.product;
    delete response.importSpec.configSpec.vAppConfig.property;
    delete response.importSpec.configSpec.vAppConfig.eula;
    delete response.importSpec.configSpec.vAppConfig.ovfSection;
    delete response.importSpec.configSpec.vAppConfig.ovfEnvironmentTransport;

This is due the fact I mentioned in the above comment.. Since the attributes are lost, the lib resorts to detecting the xsi types which sometimes turns out to be wrong. There are some minor bugs in the extendedType logics too.

Anyway thanks @bhoriuchi for this wonderful package !

from vsphere-connect.

@DrigerG thanks! it looks like i need to figure out why the attributes are getting lost. And any suggestions on how to improve the extendedType logic is welcome. I admittedly am not an expert with soap/wsdl and do not devote a lot of time to this project.

from vsphere-connect.

One top of the head logical flaw I saw was the extendedType closest match was comparing the intersection length with the parentType to begin with, which is kinda wrong. Thats what happens in the above case when it encounters ImportSpec.

say I pass 3 params
The ImportSpec has 2 params
The VirtualMachineImportSpec has 1 additional param
The intersection sees 2 > 1 and ignores the VirtualMachineImportSpec

from vsphere-connect.

@bhoriuchi would you mind If we push some pull requests to fix any bugs we see ?

from vsphere-connect.

@DrigerG yes please! I'll try to add some contributing guidelines so people know this project is open to PRs.

from vsphere-connect.

@bhoriuchi Thanks !
In the mean time I am trying to see if v1 solves @nagavenkatab 's code

from vsphere-connect.

@DrigerG what do you think about bringing all the code from the soap client soap-connect into this library? That whole module was written to support this one and while i like the idea of having it as a standalone module i doubt i will ever have time to make it a full featured soap client and it would make development on this project easier.

from vsphere-connect.

@bhoriuchi I agree 100 percent. v1.1.1 is simpler to debug and faster to develop because its in a single project

from vsphere-connect.

I just used v1 to generate @nagavenkatab's ImportSpec and used it in V2 after some xsi label massaging and the import works perfectly !!!

May be we need to revisit v2's attribute returning capability

from vsphere-connect.

@DrigerG I'm going to add the soap-connect code in and set up a lint config and a framework for tests in the development branch so that there are some initial guidelines for that stuff.

from vsphere-connect.

@DrigerG I have updated the lib to include the soap client code, added an eslintrc, test example, and basic contributing guide. feel free to submit PRs.

from vsphere-connect.

the master seems to have this issue now:

ReferenceError: babelHelpers is not defined
    at new SoapConnectClient (C:\testvc\node_modules\vsphere-connect\index.js:1627:9)

from vsphere-connect.

building with rollup has always been problematic. i have switched the build to just use babel. it will now build to dist/

from vsphere-connect.