cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Frank Zhang <>
Subject RE: VmWare SDK to vijava
Date Tue, 24 Sep 2013 20:10:23 GMT
Agree. Given current CloudStack code base changing something to another thing is really not
a good way.
As Darren is working on modular spring, why not construct a new VMWare plugin separately using
Then we can reduce the risk of surprising existing customer and switch to new module when
it finally gets mature.

> -----Original Message-----
> From: Kelven Yang []
> Sent: Tuesday, September 24, 2013 11:59 AM
> To:
> Subject: Re: VmWare SDK to vijava
> 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 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 i 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 wdsl
> >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 is
> >> where CloudStack VMware integration began with. Starting from 5.1,
> >> VMware no longer provides the java binding in binary form and
> >> recommends its customers to generate directly from its WS WSDL.
> >>
> >> Since we are not sure if we can distribute VMware wsdl legally or
> >>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 of 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 open 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 by VMware  as an commercial entity. So I see
> >>more business value to stick with 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" <> wrote:
> >>
> >>> We have been having this discussion on moving vmware out of noredist
> >>>since i joined the project. So no real need to rush this suddenly.
> >>>Still
> >>> it would be nice to get this in for the next release. The feature
> >>>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
> >>>the changes  finished this week. Then it's up to the test results if
> >>>we can make it  into the 4.3 release or the 4.4 release. Of course
> >>>all pending a  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 the 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 then 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 that 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
> >>>>>>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
> >>>>>>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
> >>>>>>>>VMware and vijava  so my  comments may be off base (everything
> >>>>>>>>know about vmware client is  based  off about 2 hours
> >>>>>>>>googling), but my gut reaction is that its  better to
> >>>>>>>>with mainstream than use vijava.  I understand the VMware
> >>>>>>>>is a  complicated and weird API.  But the fact that you
> >>>>>>>>drop vijava  in real  quick and it mostly matches the
> >>>>>>>>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
> >>>>>>>>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
> >>>>>>>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
> >>>>>>>there are some changes. A nice  example is on the vijava
> >>>>>>>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
> >>>>>>>
> >>>>>>>>
> >>>>>>>> Additionally, if somebody wants to know how to do something
> >>>>>>>>with  VMware or  why something isn't working, I'd rather
> >>>>>>>>them to the VMware SDK  documentation than vijava.  I
> >>>>>>>>assume that there is going to  be more  information about
> >>>>>>>>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 vmware 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
> >>>>>>>>bindings are  not the  same thing.  VMware API is first
> >>>>>>>>foremost a SOAP service.  The  java  bindings they provide
> >>>>>>>>just a convenience in that they already  generated  the
> >>>>>>>>stubs for you.  But if I was to consume any other SOAP
> >>>>>>>>in the world, I would be generating my client stubs for
it.  So
> >>>>>>>>this is  just the normal approach you take to consume
> >>>>>>>>webservice.
> >>>>>>>> Typically you
> >>>>>>>> generate the stubs as part of the build and never check-in
> >>>>>>>>generated  code to git, but I don't think we can check
> >>>>>>>>vmware wsdl into  git (if we  could, that would be ideal).
> >>>>>>>>basically, if I'm generating  stubs or I'm  using a java
> >>>>>>>>its about the same overhead.  If the webservice  moves
> >>>>>>>>version X, I generate new stubs against version X of
the wsdl.
> >>>>>>>> If the
> >>>>>>>> jar changes to version X, I update the pom dependency
> >>>>>>>>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.
> >>>>>>>>guess it would be  helpful if  you could illustrate some
of the
> >>>>>>>>benefits of vijava.  I know you  wanted to  get it working
> >>>>>>>>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
> >>>>>>>>and  distributable.
> >>>>>>>
> >>>>>>> Stay tuned and follow the commits :-)
> >>>>>>>
> >>>>>>>
> >>>>>>>>
> >>>>>>>> Darren
> >>>>>>>
> >>>>>>> Cheers,
> >>>>>>>
> >>>>>>> Hugo
> >>>>>
> >>>
> >>
> >

View raw message