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