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