Some type, in this case 'Task' is not defined in the specified namespace(urn:nfc). In such case, the deserializer will have to guess the namespace by interate namesapce in the _wsdlTypeMapNSs. 'Task' exists in multiple namespaces. In python2, the order in the map is fixed and vim25 is always tried first, but in python3 the order of the set is random. If wrong namespace is returned, the xml parser will fail later on.
VC is returning some internal managed method in 6.0. Looks like this issue
will be resolved in 6.5 server types as it will be public in 6.5. To tempoarily
workaound this issue, returning a dummy method and dummy obj instead of throwing
exception when client side can't understand the returned managed method.
pyvmomi objects can be resolved by the vmodl name, e.g. "vim.vm.RelocateSpec"
or by the wsdl name, e.g. "vim.VirtualMachineRelocateSpec".
The wsdl name resolution uses "vim" as a hard-coded name, and doesn't
resolve more wsdl namespaces like "sms" and "pbm"
1. Remove the encode() helper method since it doesn't provide encoding in python3 at all.
2. In order to workaround the leading 'b' literal after encoding in python3,
we delay the encoding step and will encode the whole soap message instead of individual values.
3. Added separate cases to handle Enum, integer and float to make the serializtion process more clear.
The Add method for _BuildVersions will get only
the first component of the namespace and use that as
a key for the dictionary. However that's a problem for
a namespace like hbr which has 3 sub-namespaces:
hbr.agent, hbr.cascadeAgent and hbr.replica because
newestVersions will only save hbr.replica.version.version5
as HbrReplicaTypes is the first one that's imported
in pyVmomi/__init__.py.
This change adds the following behavior: if you add a
version 'x.y.z.version.version1', it will try
to add it as 'x' (for backwards compatibility) and 'x.y.z'.
As per python docs, "There are no implied relationships among the comparison operators. The truth of x==y does not imply that x!=y is false. Accordingly, when defining __eq__(), one should also define __ne__() so that the operators will behave as expected"
Hence, implementing __ne__ to enable '!='
Since introduction of meta-versions and related
generated versions, we need facility, allowing
code to specify those versions during run-time.
(Note that although version classes are well-
defined, the particular versions that correspond
to a class change from build to build, depending
on meta-version state.)
Since introduction of meta-versions and related
generated versions, we need facility, allowing
code to specify those versions during run-time.
(Note that although version classes are well-
defined, the particular versions that correspond
to a class change from build to build, depending
on meta-version state.)
The import statement for Iso8601 was not properly
updated. This fix changes the import statement so
it works properly after python3 support changes.
fixes https://github.com/vmware/pyvmomi/issues/112
* Malformed Faults: introduces test for fault handler
* introduces ParserError which includes the malformed XML
* testing demonstrates ParserError includes malformed XML
closes: https://github.com/vmware/pyvmomi/issues/72
A minimal change set to deal with unicode modules and methods between
python2 and python3. A deeper reworking of the unicode components
is very likely called for, however, this change should get the library
working on python3.
partial: https://github.com/vmware/pyvmomi/issues/55
This is the initial version of pyVmomi which represents vSphere API 5.1.
Going forward, expect only the 'Objects' and 'Types' generated source
files to need updating via official OSS drops.
