cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kelven Yang <>
Subject Re: VmWare SDK to vijava
Date Wed, 25 Sep 2013 00:30:40 GMT

On 9/24/13 4:54 PM, "Alex Huang" <> wrote:

>> -----Original Message-----
>> From: Alex Huang []
>> Sent: Tuesday, September 24, 2013 4:23 PM
>> To:
>> Subject: RE: VmWare SDK to vijava
>> So this discussion took a big turn that I did not expect.  I am very
>> against creating a "plugin" layer just to interface with VmWare.  I
>> both the effort from Darren and Hugo and each hold some merit.  I think
>> should discuss this out and drive a consensus rather than spending time
>> create "plugin" layers and such.
>> For me, I prefer going directly to wsdl because the helper layer (both
>> and vijava) is so thin that it's not a lot of effort to reproduce.
>>Going directly
>> to wsdl has the following advantages:
>>   - We don't have to worry about upgrades in the helper libraries.
>>Look at
>> what happened on 4.2 vim25 upgrade and the change in hidden behavior
>> changes that caused lots of bugs.  It just doesn't seem to be worth the
>> to deal with third party helper libraries for the small amount of code
>>   - With wsdl, we can generate with different package names so that
>> two different versions of wsdls can have two different set of stub
>>classes so
>> we avoid using java class loaders to distinguish between the two.
>I want to elaborate specifically on this point a little bit.  In a
>production deployed cloud that has been around, there's bound to be
>hypervisors of different versions.  We have that problem with XenServer
>because it is version that's been supported by CloudStack the longest.
>CloudStack deals with the different versions of the same Hypervisor by
>writing two different ServerResources (they might share a common base of
>course).  However, if the client stubs the different ServerResources talk
>to are also of different versions but with the same name, then we have to
>work on confining different versions of the client stubs to different
>class loaders.  That's a lot of effort to do something simple.  Instead,
>we can simply designate a different package name when  generating from
>the wsdl (assuming the different versions of client stubs is due to wsdl
>versioning differences when interfacing with different versions of
>hypervisor) and have the ServerResources just refer to the different
>client stubs generated.  Hence, I prefer generation directly from wsdl.

This is my major point as well. VMware API itself is already complex and
we already have wrapped it into isolated MO class layer, it may not be as
complete as what vijava has but it pretty-much has served the needs for
CloudStack, and as far as CloudStack concerns, we really don't need a
full-around API wrapper. I would rather to refactor our MO class layer to
not leak VMware low-level objects first and make the isolation layer fully
neutral to wsdl/xyz wrapper, than to make a dramatic switch right now. The
time should be spent for what is more worth.

The less dependency in the middle, the more flexible we will gain in cases
like the one we elaborate.



View raw message