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 21:27:58 GMT
I'm fine with that, but I'd say that modular boundary like this is too
blurring that may end up to too much code divergency. If we can't state
clearly about the boundary, then the cut will drag other pieces along with
it. there are other logic being built between CloudStack and VMware API in
resource level, we only want to cut at the place we really want and be
able to share common work.

Kelven

On 9/24/13 2:16 PM, "Frank Zhang" <Frank.Zhang@citrix.com> wrote:

>Emm, I am saying totally creating new VMWare
>resource/discover/manager/guru
>as a plugin where each component for example VMWareResource is a module
>in plugin.
>This matches Darren's plugin proposal. and you (Kelven) could continue
>maintaining current
>implementation for backward compatibility. And community who is
>interested in vijava could
>develop own stuff with little concerns about current customers.
>   
>
>> -----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