On 9/24/13 4:22 PM, "Alex Huang" <alex.hu...@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.y...@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.zh...@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.y...@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" <h...@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.y...@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" <h...@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.sheph...@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 >> >> >>>>><h...@trippaers.nl> >> >> >>>>>wrote: >> >> >>>>> >> >> >>>>> >> >> >>>>>> On Sep 23, 2013, at 1:39 PM, Darren Shepherd >> >> >>>>>> <darren.s.sheph...@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 >> >> >>>>>>> <h...@trippaers.nl> >> >> >>>>>>> wrote: >> >> >>>>>>> >> >> >>>>>>> >> >> >>>>>>>> On Sep 23, 2013, at 1:01 PM, Darren Shepherd >> >> >>>>>>>> <darren.s.sheph...@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 >> >> >>>>> >> >> >>> >> >> >> >> >> > >> > >
