That clears up a lot, I didn't know how to get in touch with Prussia. Darren
> On Sep 24, 2013, at 7:09 PM, Hugo Trippaers <trip...@gmail.com> wrote: > > 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 >>
