cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kelven Yang <kelven.y...@citrix.com>
Subject Re: VmWare SDK to vijava
Date Tue, 24 Sep 2013 23:35:27 GMT


On 9/24/13 4:22 PM, "Alex Huang" <Alex.Huang@citrix.com> wrote:

>So this discussion took a big turn that I did not expect.  I am very
>strongly against creating a "plugin" layer just to interface with VmWare.
> I appreciate both the effort from Darren and Hugo and each hold some
>merit.  I think we should discuss this out and drive a consensus rather
>than spending time to create "plugin" layers and such.
>
>For me, I prefer going directly to wsdl because the helper layer (both
>vim25 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
>time to deal with third party helper libraries for the small amount of
>code gain.
>  - With wsdl, we can generate with different package names so that using
>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.

+1, although I don't want to disappoint developer's motivations. The wsdl
approach makes more business sense to me.

-kelven

> 
>
>Please, let's discuss on this and drive a consensus together rather than
>try to accommodate all.
>
>--Alex
>
>> -----Original Message-----
>> From: Kelven Yang [mailto:kelven.yang@citrix.com]
>> Sent: Tuesday, September 24, 2013 2:06 PM
>> To: dev@cloudstack.apache.org
>> Subject: Re: VmWare SDK to vijava
>> 
>> It is about the interface layer between CloudStack and VMware, Spring
>>can
>> only help to what it can, ultimately, we need to refactor the interface
>>layer to
>> take in vijava as one of its implementations.
>> 
>> We also need to consider of another situation, with the latest vSphere
>>5.1
>> API, although VMware claims to support all previous vSphere versions
>>with it,
>> we actually found that this is not true. We may have to face the fact
>>that we
>> will need to support two versions of vSphere APIs at run time
>>side-by-side.
>> I'm leaning towards for us to to have some control in generating the
>>API stub
>> for this(the direct WSDL way), if it is to vijava, it depends on
>>whether or not it
>> has built-in side-by-side VMware API support. and we will have more
>>things
>> to worry and test about it.
>> 
>> Kelven
>> 
>> 
>> On 9/24/13 1:10 PM, "Frank Zhang" <Frank.Zhang@citrix.com> wrote:
>> 
>> >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 vijava?
>> >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 [mailto:kelven.yang@citrix.com]
>> >> Sent: Tuesday, September 24, 2013 11:59 AM
>> >> To: dev@cloudstack.apache.org
>> >> 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" <hugo@trippaers.nl> 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 <kelven.yang@citrix.com>
>> >>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" <hugo@trippaers.nl>
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
>> >> >>> <darren.s.shepherd@gmail.com> 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
>> >> >>>>><hugo@trippaers.nl>
>> >> >>>>>wrote:
>> >> >>>>>
>> >> >>>>>
>> >> >>>>>> On Sep 23, 2013, at 1:39 PM, Darren Shepherd
>> >> >>>>>> <darren.s.shepherd@gmail.com> 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
>> >> >>>>>>> <hugo@trippaers.nl>
>> >> >>>>>>> wrote:
>> >> >>>>>>>
>> >> >>>>>>>
>> >> >>>>>>>> On Sep 23, 2013, at 1:01 PM, Darren Shepherd
>> >> >>>>>>>> <darren.s.shepherd@gmail.com> 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
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
>> >> >>>>>>>>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
>> >> >>>>>
>> >> >>>
>> >> >>
>> >> >
>> >
>


Mime
View raw message