Hahah, Yeah indeed, awful autocorrect.
Sent from my iPhone > On 25 sep. 2013, at 10:01, Chiradeep Vittal <chiradeep.vit...@citrix.com> > wrote: > > 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 >
