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.vit...@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" <trip...@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.sheph...@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 <h...@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.y...@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" <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 > >>>
