Heya, I've just pushed two changes to the master tree,
First one (https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a=commit;h=e3f2cf908a32e1ea2a0415474bf708112f52099c): The PremiumSecondaryStorageResource is now only used if the hypervisor is VmWare. I think we can safely assume that anyone with a VmWare hypervisor will have built/installed the necessary components to get this going. Second one (https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a=commit;h=b1d52c4404a69ead94bbb01ff38f6707d72b0841): I've made the inclusion of vmware.jar optional in the systemvm packaging. It is controlled by the property 'ssvm.include.vmware.jar'. For now this is set from build-cloud.properties, but this can be set just like any other ant propertie. For example by testing if the library is in the expected location. Any feedback on this solution? Otherwise I will push it to the 4.0 branch as well. Cheers, Hugo -----Original Message----- From: Mice Xia [mailto:weiran.x...@gmail.com] Sent: Wednesday, August 22, 2012 1:52 AM To: cloudstack-dev@incubator.apache.org Subject: Re: [DISCUSS] VMware support was: Re: vijava - some additional thoughts default build target does not build vmware jar, and another build target provided for users should build this jar and include it in systemvm.zip. management server can either read a conf from component.xml or simply class.for() to determine which resourseLibrary the agent in ssvm should launch from. if users want to 'upgrade' a non-vmware build to a vmware build, it.may need some manual steps like destroying ssvm and its template from primay storage.. my ¥0.02 Mice > Heya, > > Just noticed that the systemvm image (still) depends on > cloud-vmware.jar, if we strip this from the distribution we need to change the storage VM to not use the premium storage service but the regular nfs storage service. See > https://reviews.apache.org/r/6320/ > https://reviews.apache.org/r/5804/ > > What to do? > > Cheers, > > Hugo > > -----Original Message----- > From: David Nalley [mailto:da...@gnsa.us] > Sent: Friday, August 10, 2012 3:19 PM > To: cloudstack-dev@incubator.apache.org > Subject: Re: [DISCUSS] VMware support was: Re: vijava - some > additional thoughts > > On Fri, Aug 10, 2012 at 6:51 AM, Tamas Monos <tam...@veber.co.uk> wrote: >> Hi, >> >> Do vmware libraries really need to be removed and re-added manually? >> Could ASF not acquire permission from Vmware to redistribute their freely available sdk for this project? >> This 4.0 would be the first big ASF release and you want to cripple vmware support? >> > > It's a bit more complicated than removing and re-adding. You also need > to recompile CloudStack (or at least the vmware plugin + vmware base), but if you are going to that trouble you might as well just compile the entire thing from source. > > The problem is also more complicated than that - there are two files > that are freely redistributable (for certain constrained definitions of freely redistributable that involve, among other things, agreeing to indemnify VMware) vim.jar and vim25.jar. However the current implementation also makes use of vmware-apputils.jar (and another open source-based library) which is not freely redistributable based on my reading. > > The ASF could likely get permission to redistribute those files, but > that permission wouldn't extend to other folks. Besides there are at least two other potential solutions to the problem that don't have the same license problems. (We are after all an open source software > project) > > --David > -- Sent from Gmail Mobile
