incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chip Childers <chip.child...@sungard.com>
Subject Re: combining vmware-base and plugin/hypervisor/vmware?
Date Thu, 13 Sep 2012 16:55:50 GMT
On Thu, Sep 13, 2012 at 11:26 AM, Hugo Trippaers
<HTrippaers@schubergphilis.com> wrote:
>
>
> Verstuurd vanaf mijn iPad
>
> Op 13 sep. 2012 om 14:05 heeft "Murali Reddy" <Murali.Reddy@citrix.com> het volgende
geschreven:
>
>> On 11/09/12 7:25 PM, "Hugo Trippaers" <HTrippaers@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.Reddy@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" <HTrippaers@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.childers@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
>>>>>> <HTrippaers@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
>>>>>
>>>>
>>>
>>>
>>
>>
>

Mime
View raw message