cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Huang <Alex.Hu...@citrix.com>
Subject RE: VmWare SDK to vijava
Date Wed, 25 Sep 2013 01:51:46 GMT
Agreed.  If we can do it is the big question.  Although, AFAIK, vijava is also generated from
the same set of wsdl.  So if we can't get the license, I have to wonder how did vijava get
their BSD license?

--Alex

> -----Original Message-----
> From: Darren Shepherd [mailto:darren.s.shepherd@gmail.com]
> Sent: Tuesday, September 24, 2013 6:07 PM
> To: dev@cloudstack.apache.org
> Cc: dev@cloudstack.apache.org
> Subject: Re: VmWare SDK to vijava
> 
> 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 <hugo@trippaers.nl> 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 <kelven.yang@citrix.com>
> 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" <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