On Thu, Sep 13, 2012 at 11:26 AM, Hugo Trippaers <htrippa...@schubergphilis.com> wrote: > > > Verstuurd vanaf mijn iPad > > Op 13 sep. 2012 om 14:05 heeft "Murali Reddy" <murali.re...@citrix.com> het > volgende geschreven: > >> On 11/09/12 7:25 PM, "Hugo Trippaers" <htrippa...@schubergphilis.com> >> wrote: >> >>> Hey Murali, >>> >>> If that is the case, should the Premium storage class not be in >>> vmware-base? It is now in the plugin, so the plugin needs to be installed >>> in the system vm for vmware support to work anyway? >>> >>> Cheers, >>> >>> Hugo >>> >> >> No, I think premium storage class could be a separate Jar. > > Does this mean we should actually have three components? The plugin for the > hypervisor VMware, the plugin for the VMware secondary storage and a library > with VMware convenience code?
IMO, yes. That's what I was expecting when I suggested keeping vmware-base as the location for common vmware API bridge code, and that we would have vm-ware specific plugins of various types (more than just "compute / hypervisor"). > >> Ideally we >> would should have a way for plugin's to tell what component/jar's should >> go in to management server and system VM's. Right now there is single >> plugin that is packaged into both server and system VM. > > I thinking we can do this with profiles in maven. When the flag VMware is > enabled the systemvm build could be configured to include the VMware jars. > > >> >> Vmware-base is just convenience library which does not have CloudStack >> functionality. My only concern is if that is merged into Vmware-plugin, >> over the time, it get coupled with the hypervisor specific code. > > Good point. >> >> >>> >>>> -----Original Message----- >>>> From: Murali Reddy [mailto:murali.re...@citrix.com] >>>> Sent: Tuesday, September 11, 2012 12:25 PM >>>> To: cloudstack-dev@incubator.apache.org >>>> Subject: Re: combining vmware-base and plugin/hypervisor/vmware? >>>> >>>> On 11/09/12 1:18 PM, "Hugo Trippaers" <htrippa...@schubergphilis.com> >>>> wrote: >>>> >>>>> Hey Chip, >>>>> >>>>> Good point, but by looking at the code it seems the other way around. >>>>> Most of the generic stuff is inside the plugin (including parts of the >>>>> code for the cisco nexus integration and the vmware version of the >>>>> SSVM) and in particular the hypervisor code is in the vmware-base. >>>>> >>>>> For now I think it is more clear if we combine everything in the vmware >>>>> plugin directory, should there be a need we can always separate the >>>>> interface. For now I think it's unlikely that something is done via the >>>>> vmware api that is not directly related to the vmware hypervisor (or >>>>> used by peeps that don't use the vmware hypervisor). >>>>> >>>>> Cheers, >>>>> >>>>> Hugo >>>> >>>> When I initially moved vmware into a plug-in, I left vmware-base as >>>> independently buildable jar, so that it can packaged to systemvm.iso and >>>> management server separately. SSVM (which gets vmware version of >>>> secondary storage resource from systemvm.iso) just need vmware-base, not >>>> complete vmware plug-in. >>>> >>>> How about moving vmware-base stuff into plugin/hypervisor/vmware folder >>>> but still retain project & jar for it? So if need arises its easy to >>>> move it out. >>>>> >>>>>> -----Original Message----- >>>>>> From: Chip Childers [mailto:chip.child...@sungard.com] >>>>>> Sent: Monday, September 10, 2012 3:39 PM >>>>>> To: cloudstack-dev@incubator.apache.org >>>>>> Subject: Re: combining vmware-base and plugin/hypervisor/vmware? >>>>>> >>>>>> On Mon, Sep 10, 2012 at 3:23 AM, Hugo Trippaers >>>>>> <htrippa...@schubergphilis.com> wrote: >>>>>>> Heya, >>>>>>> >>>>>>> Anybody against moving all sources from vmware-base to >>>>>> plugin/hypervisors/vmware? It seems more logical to combine these two >>>>>> trees and make it a single plugin. >>>>>>> >>>>>>> Cheers, >>>>>>> >>>>>>> Hugo >>>>>> >>>>>> Hey Hugo, >>>>>> >>>>>> There might be a reason to keep it broken out. For example, let's >>>>>> say that I wanted to build a different plugin type that uses the >>>>>> VMware API. >>>>>> >>>>>> -chip >>>>> >>>> >>> >>> >> >> >
