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 03:01:36 GMT
Wow good guess...Hugo had me scratching my head on that one....Is Prussian some code name for
Apache legal....Should I ask....Would it make me look stupid if I asked....all sorts of doubts
going through my mind.

--Alex

> -----Original Message-----
> From: Chiradeep Vittal [mailto:Chiradeep.Vittal@citrix.com]
> Sent: Tuesday, September 24, 2013 7:01 PM
> To: dev@cloudstack.apache.org
> Subject: Re: VmWare SDK to vijava
> 
> Ha! Prussians == Prasanna?
> Godawful autocorrect.
> 
> On 9/24/13 6:47 PM, "Hugo Trippaers" <trippie@gmail.com> 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
> >><darren.s.shepherd@gmail.com> 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 <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