cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hugo Trippaers <>
Subject Re: VmWare SDK to vijava
Date Wed, 25 Sep 2013 02:09:35 GMT

Yeah indeed, awful autocorrect.

Sent from my iPhone

> On 25 sep. 2013, at 10:01, Chiradeep Vittal <> wrote:
> Ha! Prussians == Prasanna?
> Godawful autocorrect.
>> On 9/24/13 6:47 PM, "Hugo Trippaers" <> wrote:
>> Darren, you can probably work with Prussians to get it through the bvt
>> suite. That would be a nice start.
>> Cheers,
>> Hugo
>> Sent from my iPhone
>>> On 25 sep. 2013, at 09:06, Darren Shepherd
>>> <> wrote:
>>> My extensive testing consisted of "it compiles!"  So somebody needs to
>>> validate it, I don't have a vmware setup handy.  The wsdl generation
>>> route is not feasible unless legal says it's okay.  Somebody want to
>>> email legal@?
>>> Darren
>>>> On Sep 24, 2013, at 5:27 PM, Hugo Trippaers <> wrote:
>>>> So at this moment we have the following tally,
>>>> Darren, Alex, Kelven opt for the wsdl route
>>>> Hugo opts for the vijava route
>>>> I'm perfectly ok with ditching my work on the vijava in favour of the
>>>> wsdl route. The arguments presented in the last few mails make a lot of
>>>> sense. So i say the wsdl route is the way to go.
>>>> I do think however that we need to revisit the vmware code anyway.
>>>> There is dead code in there, formatting issues and a general
>>>> duplication of code. Parts of my plan to switch to vijava was to
>>>> simplify the code as well, but i can still do that with the WSDL layer.
>>>> Darren, did you run your wsdl branch through the BVT test suite? If
>>>> you did we can merge it on short notice and get on with it. If you
>>>> didn't can you take care of that and give an overview of the testing
>>>> done on that branch besides the BVT?
>>>> Cheers,
>>>> Hugo
>>>>> On Sep 25, 2013, at 2:58 AM, Kelven Yang <>
>>>>> wrote:
>>>>> We have commercial releases on top of existing code base and there are
>>>>> lots of testing efforts behind it, dramatic switch means $ cost, the
>>>>> major
>>>>> concern for me is not about how beautiful vijava is or how bad a
>>>>> direct
>>>>> wsdl approach would be. it is about to get things move smoothly.
>>>>> It looks like that we should have VMware layer on its own to have a
>>>>> plugin
>>>>> structure so that we can replace underlying binding easier, it should
>>>>> solve the balance between developer's tho motivation and carrying on
>>>>> the
>>>>> legacy with minimal impacts to the rest of others.
>>>>> Kelven
>>>>>> On 9/23/13 6:01 PM, "Hugo Trippaers" <> wrote:
>>>>>> Heya,
>>>>>> This biggest advantage i see in using vijava is that a lot of the
>>>>>> functionality that we now have in the vmware-base project is already
>>>>>> supplied with vijava.
>>>>>> There is a lot of code that facilitates calling tasks and other
>>>>>> stuff in
>>>>>> our MO classes. These classes are available in vijava and could be
>>>>>> used
>>>>>> instead of our classes. Basically when using vijava correctly you
>>>>>> hardly
>>>>>> have to work with the ManagedObjectReferences anymore. For me this
>>>>>> would
>>>>>> be a big benefit as it makes programming against vmware a lot
>>>>>> easier. We
>>>>>> also have a lot of duplicate code currently in the vmware class and
>>>>>> wouldn't mind getting rid of it, which i think is easier with the
>>>>>> vijava
>>>>>> libraries.
>>>>>> That said, the main driver is getting it into the main build so any
>>>>>> other
>>>>>> efforts towards that goal are ok with me.
>>>>>> I would propose that somebody else puts up a branch with our own
>>>>>> wrapper and we open a discussion thread when both branches are ready
>>>>>> to
>>>>>> see which we want to merge in master. Anybody who wants to pick that
>>>>>> up?
>>>>>> I'm stubbornly going to continue with converting to vijava, I put
>>>>>> some
>>>>>> effort into it and i want at least to see it running once ;-)  And
>>>>>> the
>>>>>> more i work with it the more i'm seeing to benefits of the library
>>>>>> so i
>>>>>> might be able to be more convincing in the end :-)
>>>>>> Cheers,
>>>>>> Hugo
>>>>>>> On Sep 24, 2013, at 2:18 AM, Kelven Yang <>
>>>>>>> wrote:
>>>>>>> Prior to 5.1, VMware provides java binding in its SDK and this
>>>>>>> where
>>>>>>> CloudStack VMware integration began with. Starting from 5.1,
>>>>>>> no
>>>>>>> longer provides the java binding in binary form and recommends
>>>>>>> customers to generate directly from its WS WSDL.
>>>>>>> Since we are not sure if we can distribute VMware wsdl legally
>>>>>>> not,
>>>>>>> therefore, we ended up to generate and distribute the java binding
>>>>>>> in
>>>>>>> binary form. If we can get this cleared in lebal, as Darren
>>>>>>> pointed, we
>>>>>>> can solve our non-dist issue easily in matter of adding couple
>>>>>>> lines
>>>>>>> in
>>>>>>> maven.
>>>>>>> As of vijava, yes, I think it may add some value from developer's
>>>>>>> point
>>>>>>> of
>>>>>>> view, but on the other hand, I don't see immediate benefits to
>>>>>>> having
>>>>>>> another layer on top of VMware official WS API, vijava is an
>>>>>>> source
>>>>>>> project for providing convenient java binding to vmware WS API,
>>>>>>> maybe
>>>>>>> I'm
>>>>>>> wrong, but I think VMware vSphere WS API is the only official
>>>>>>> published
>>>>>>> API from VMware, and the testing result of the API is endorsed
>>>>>>> VMware
>>>>>>> as an commercial entity. So I see more business value to stick
>>>>>>> the
>>>>>>> official WS API directly. If we can clear the legal concern of
>>>>>>> redistributing VMware wsdl. I would +1 to add a build step of
>>>>>>> generating
>>>>>>> VMware java binding from wsdl.
>>>>>>> Kelven
>>>>>>>> On 9/23/13 12:40 AM, "Hugo Trippaers" <>
>>>>>>>> We have been having this discussion on moving vmware out
>>>>>>>> noredist
>>>>>>>> since i joined the project. So no real need to rush this
>>>>>>>> Still
>>>>>>>> it would be nice to get this in for the next release. The
>>>>>>>> freeze
>>>>>>>> of 4.3 is october 31st for the 4.3 release. This change (or
any sdk
>>>>>>>> change to vmware) should be considered an architecture change
so it
>>>>>>>> should come in at the start of the new release cycle.
>>>>>>>> So this is currently my main activity on CloudStack meaning
i can
>>>>>>>> work
>>>>>>>> pretty much dedicated on this. With a bit of luck i can have
>>>>>>>> changes
>>>>>>>> finished this week. Then it's up to the test results if we
>>>>>>>> make it
>>>>>>>> into the 4.3 release or the 4.4 release. Of course all pending
>>>>>>>> successful merge vote.
>>>>>>>> Cheers,
>>>>>>>> Hugo
>>>>>>>> On Sep 23, 2013, at 3:10 PM, Darren Shepherd
>>>>>>>> <> wrote:
>>>>>>>>> It's seems there could be some good merit to adopting
vijava.  I
>>>>>>>>> hate
>>>>>>>>> to belabor this point, but we could get vmware plugin
out of
>>>>>>>>> noredist
>>>>>>>>> real fast if we just generate bindings (I think)
>>>>>>>>> Do you know if legally we can add the vmware wsdl to
git?  We
>>>>>>>>> wouldn't
>>>>>>>>> redistribute it in the binary builds.  If we could add
the wsdl to
>>>>>>>>> git,
>>>>>>>>> I could add a couple lines to the Pom and it will generate
>>>>>>>>> bindings
>>>>>>>>> as part of the build.  Then vmware will be fully redistributable
>>>>>>>>> and
>>>>>>>>> there is no change to existing code.  At runtime everything
>>>>>>>>> should be
>>>>>>>>> the same too.  We could make that change real fast and
>>>>>>>>> additionally
>>>>>>>>> continue to look at vijava.
>>>>>>>>> Personal I want to get rid of noredist.  If somebody
wants to
>>>>>>>>> contribute code that depends on nonfree code, it seems
>>>>>>>>> should be
>>>>>>>>> in
>>>>>>>>> a cloudstack-nonfree repo.
>>>>>>>>> Darren
>>>>>>>>>> On Sep 22, 2013, at 11:43 PM, Hugo Trippaers <>
>>>>>>>>>> wrote:
>>>>>>>>>>> On Sep 23, 2013, at 1:39 PM, Darren Shepherd
>>>>>>>>>>> <> wrote:
>>>>>>>>>>> Yeah, I'll dig into it more.  I think I understand
a bit that
>>>>>>>>>>> vmware
>>>>>>>>>>> api is just a bunch of generics objects, so another
library on
>>>>>>>>>>> top
>>>>>>>>>>> to
>>>>>>>>>>> create types on top of it helps.  So I'll look
at it more.  In
>>>>>>>>>>> the
>>>>>>>>>>> end
>>>>>>>>>>> I'm still going to probably have reservations
about 1) a custom
>>>>>>>>>>> XML/soap framework 2) a third party maintained
later between us
>>>>>>>>>>> and
>>>>>>>>>>> vmware (sorta like libvirt-java always behind
and incomplete
>>>>>>>>>>> with
>>>>>>>>>>> native libvirt).  So it just depends on if the
nicer api is
>>>>>>>>>>> worth
>>>>>>>>>>> the
>>>>>>>>>>> risk of the other things.  I don't think vmwares
api changes
>>>>>>>>>>> much,
>>>>>>>>>>> and
>>>>>>>>>>> you can always get to the generic objects so
maybe my concerns
>>>>>>>>>>> are
>>>>>>>>>>> moot.  
>>>>>>>>>> Thanks, i could actually use a second pair of eyes
if we want to
>>>>>>>>>> get
>>>>>>>>>> this into master. It would be nice to have a few
people test
>>>>>>>>>> this. I
>>>>>>>>>> don't really share the concern on the XML/soap framework
one is a
>>>>>>>>>> good
>>>>>>>>>> or bad as the other usually, i've seen interesting
things with
>>>>>>>>>> the
>>>>>>>>>> axes
>>>>>>>>>> framework as well. But thats besides the point for
now. My main
>>>>>>>>>> objective now it to get vijava working with as little
changes as
>>>>>>>>>> possible. Later we can do some refactoring and see
if vijava
>>>>>>>>>> really
>>>>>>>>>> benefits us as much as i think/hope it will do.
>>>>>>>>>> Your second concern is one i share, we will have
to see how it
>>>>>>>>>> goes.
>>>>>>>>>> Vmware doesn't really change its api that often and
if it does
>>>>>>>>>> we are
>>>>>>>>>> generally not the early adopters of new versions
of libraries.
>>>>>>>>>> So for
>>>>>>>>>> now we should be ok.
>>>>>>>>>> Hopefully we will get the vmware stuff in the redistributable
>>>>>>>>>> build
>>>>>>>>>> which is the primary objective here. All benefits
are nice to
>>>>>>>>>> have
>>>>>>>>>> for
>>>>>>>>>> future developments.
>>>>>>>>>> Cheers,
>>>>>>>>>> Hugo
>>>>>>>>>>> Darren
>>>>>>>>>>>> On Sep 22, 2013, at 10:14 PM, Hugo Trippaers
>>>>>>>>>>>> <>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>> On Sep 23, 2013, at 1:01 PM, Darren Shepherd
>>>>>>>>>>>>> <> wrote:
>>>>>>>>>>>>> Oh, I thought the primary motivation
was just to get to fully
>>>>>>>>>>>>> open
>>>>>>>>>>>>> source
>>>>>>>>>>>>> and out of noredist.  I don't know enough
about VMware and
>>>>>>>>>>>>> vijava
>>>>>>>>>>>>> so my
>>>>>>>>>>>>> comments may be off base (everything
I know about vmware
>>>>>>>>>>>>> client is
>>>>>>>>>>>>> based
>>>>>>>>>>>>> off about 2 hours of googling), but my
gut reaction is that
>>>>>>>>>>>>> its
>>>>>>>>>>>>> better to
>>>>>>>>>>>>> stick with mainstream than use vijava.
 I understand the
>>>>>>>>>>>>> VMware
>>>>>>>>>>>>> wsdl is a
>>>>>>>>>>>>> complicated and weird API.  But the fact
that you could drop
>>>>>>>>>>>>> vijava
>>>>>>>>>>>>> in real
>>>>>>>>>>>>> quick and it mostly matches the existing
illustrates that its
>>>>>>>>>>>>> not
>>>>>>>>>>>>> a
>>>>>>>>>>>>> big
>>>>>>>>>>>>> departure from from the vmware bindings
so doesn't seem to
>>>>>>>>>>>>> make
>>>>>>>>>>>>> consuming
>>>>>>>>>>>>> it much easier.  It seems that vijava
was better than vmware
>>>>>>>>>>>>> sdk
>>>>>>>>>>>>> 2.5
>>>>>>>>>>>>> because you didn't need Apache Axis.
 But vSphere 5.1 sdk is
>>>>>>>>>>>>> based
>>>>>>>>>>>>> off of
>>>>>>>>>>>>> JAXWS and thus doesn't need axis anymore.
 If I'm going to
>>>>>>>>>>>>> put my
>>>>>>>>>>>>> trust in
>>>>>>>>>>>>> something at runtime I'd rather use the
sun/oracle jaxws or
>>>>>>>>>>>>> apache
>>>>>>>>>>>>> CXF and
>>>>>>>>>>>>> not some custom xml/soap framework one
guy wrote.
>>>>>>>>>>>> The drop in real quick bit is just for starters.
Some of the
>>>>>>>>>>>> enums
>>>>>>>>>>>> have changes names and instead of lists vijava
uses arrays.
>>>>>>>>>>>> Those
>>>>>>>>>>>> items are pretty quick to adapt. The real
interesting things
>>>>>>>>>>>> are in
>>>>>>>>>>>> the serviceInstance etc. That's where there
are some changes. A
>>>>>>>>>>>> nice
>>>>>>>>>>>> example is on the vijava website where 100
lines of "regular"
>>>>>>>>>>>> vmware
>>>>>>>>>>>> sdk is replaced by 20-something lines of
vijava. I'd say dig a
>>>>>>>>>>>> bit
>>>>>>>>>>>> deeper and i could use the help with the
conversion process.
>>>>>>>>>>>>> Additionally, if somebody wants to know
how to do something
>>>>>>>>>>>>> with
>>>>>>>>>>>>> VMware or
>>>>>>>>>>>>> why something isn't working, I'd rather
point them to the
>>>>>>>>>>>>> VMware
>>>>>>>>>>>>> SDK
>>>>>>>>>>>>> documentation than vijava.  I would assume
that there is
>>>>>>>>>>>>> going to
>>>>>>>>>>>>> be more
>>>>>>>>>>>>> information about the VMware library
then there would be for
>>>>>>>>>>>>> vijava
>>>>>>>>>>>>> on
>>>>>>>>>>>>> stackoverflow and google in general.
>>>>>>>>>>>> Google it, so far you are right, but java
projects are
>>>>>>>>>>>> switching.
>>>>>>>>>>>> Don't forget that vijava is sort of an official
>>>>>>>>>>>> project. It
>>>>>>>>>>>> is
>>>>>>>>>>>> being maintained by one of their engineers
and actually
>>>>>>>>>>>> published
>>>>>>>>>>>> in
>>>>>>>>>>>> the com.vmware namespace.
>>>>>>>>>>>>> Finally, I wouldn't consider us generating
and checking in the
>>>>>>>>>>>>> JAXWS
>>>>>>>>>>>>> bindings as being overhead in maintenance.
 The xapi bindings
>>>>>>>>>>>>> are
>>>>>>>>>>>>> not the
>>>>>>>>>>>>> same thing.  VMware API is first and
foremost a SOAP service.
>>>>>>>>>>>>> The
>>>>>>>>>>>>> java
>>>>>>>>>>>>> bindings they provide are just a convenience
in that they
>>>>>>>>>>>>> already
>>>>>>>>>>>>> generated
>>>>>>>>>>>>> the client stubs for you.  But if I was
to consume any other
>>>>>>>>>>>>> SOAP
>>>>>>>>>>>>> service
>>>>>>>>>>>>> in the world, I would be generating my
client stubs for it.
>>>>>>>>>>>>> So
>>>>>>>>>>>>> this is
>>>>>>>>>>>>> just the normal approach you take to
consume a webservice.
>>>>>>>>>>>>> Typically you
>>>>>>>>>>>>> generate the stubs as part of the build
and never check-in the
>>>>>>>>>>>>> generated
>>>>>>>>>>>>> code to git, but I don't think we can
check the vmware wsdl
>>>>>>>>>>>>> into
>>>>>>>>>>>>> git (if we
>>>>>>>>>>>>> could, that would be ideal).  But basically,
if I'm generating
>>>>>>>>>>>>> stubs or I'm
>>>>>>>>>>>>> using a java jar, its about the same
overhead.  If the
>>>>>>>>>>>>> webservice
>>>>>>>>>>>>> moves
>>>>>>>>>>>>> from version X, I generate new stubs
against version X of the
>>>>>>>>>>>>> wsdl.
>>>>>>>>>>>>> If the
>>>>>>>>>>>>> jar changes to version X, I update the
pom dependency to
>>>>>>>>>>>>> version
>>>>>>>>>>>>> X.
>>>>>>>>>>>>> In
>>>>>>>>>>>>> both cases, you still have to regression
test for
>>>>>>>>>>>>> compatibility,
>>>>>>>>>>>>> so
>>>>>>>>>>>>> testing
>>>>>>>>>>>>> effort trumps all other concerns.
>>>>>>>>>>>> I would seriously consider that overhead
in maintenance. Now i
>>>>>>>>>>>> don't
>>>>>>>>>>>> even have to worry about that besides 4 lines
of dependency in
>>>>>>>>>>>> my
>>>>>>>>>>>> maven project.
>>>>>>>>>>>>> So I'd personally like it if we just
generated the stubs
>>>>>>>>>>>>> ourself
>>>>>>>>>>>>> and then
>>>>>>>>>>>>> we can move VMware plugin out of redist.
 I guess it would be
>>>>>>>>>>>>> helpful if
>>>>>>>>>>>>> you could illustrate some of the benefits
of vijava.  I know
>>>>>>>>>>>>> you
>>>>>>>>>>>>> wanted to
>>>>>>>>>>>>> get it working first so we could test
the merits of it, I'm
>>>>>>>>>>>>> just
>>>>>>>>>>>>> having a
>>>>>>>>>>>>> hard time seeing why we would even attempt
it, if we can just
>>>>>>>>>>>>> stick
>>>>>>>>>>>>> basically with what we have today, but
make it all open
>>>>>>>>>>>>> source and
>>>>>>>>>>>>> distributable.
>>>>>>>>>>>> Stay tuned and follow the commits :-)
>>>>>>>>>>>>> Darren
>>>>>>>>>>>> Cheers,
>>>>>>>>>>>> Hugo

View raw message