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 Wed, 25 Sep 2013 00:41:03 GMT


On 9/24/13 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.

Great we have reached to a common point.

>
>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.

I'm +1 for this. When I originally put vmware-base, it was intent to be a
VMware API wrapper layer, used for CloudStack but not limited to or
specific to CloudStack. But as time went by, it has been off from that
goal due to many other reasons (i.e, rush in or paste code in to catch up
release schedule). As I mentioned in one of my replies, I think it will be
worth to clean it up for good for the future. But the priority of doing so
is also low compared to other things we need to work on.

-Kelven

>
>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