[
https://issues.apache.org/jira/browse/CLOUDSTACK-885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13614460#comment-13614460
]
Mike Tutkowski commented on CLOUDSTACK-885:
-------------------------------------------
Related info from an e-mail thread:
Exactly, John ... All of what you said, plus - for example - it really puts the
onus on the plug-in developer to update the plug in whenever we add support for
a new hypervisor (say, HyperV).
I'm happy to help out with this effort to extract hypervisor knowledge away
from these plug-ins, so - if we go this route - please feel free to bring me in.
Let's see what Edison thinks.
On Mon, Mar 25, 2013 at 11:02 PM, John Burwell <[email protected]> wrote:
Mike,
+1 .. If storage plugins have to understand each hypervisor, the
support matrix becomes unmaintainably complex. We have a variety of
abstractions commonly understood by hypervisors (e.g. LUNs, I/O
streams, sockets, files, etc) that a storage can either be yielded or
manipulated by a storage plugin that it is possible to decouple
hypervisors and storage entities.
Thanks,
-John
On Mar 25, 2013, at 5:37 PM, Mike Tutkowski
<[email protected]> wrote:
> Hey Edison,
>
> So...if you think my understanding is correct (please check out the e-mail
> below), then I have a question.
>
> Do we really want to have the storage plug-ins taking on the responsibility
> of talking to the hypervisors to hook up the storage that they just created=
> ?
>
> I'm a bit familiar with how OpenStack does this and it seems that it only
> has its storage plug-ins create a volume (LUN, whatever) and then the
> framework handles the process of dealing with the hypervisor in question to
> hook up the storage.
>
> It seems like otherwise we'd need to create a utility for all storage
> plug-ins to share otherwise they'd be duplicating efforts in talking to
> hypervisors.
>
> What do you think?
>
>
> On Thu, Mar 21, 2013 at 7:52 PM, Mike Tutkowski <
> [email protected]> wrote:
>
>> Hi Edison,
>>
>> I believe I understand the requirements for the plug-in better now.
>>
>> It sounds like the flow will be as such:
>>
>> * The user executes a Compute or Disk Offering that is tied via a storage
>> tag to a Primary Storage that is associated with a plug-in.
>>
>> * The storage framework will ask the plug-in to create a volume. The
>> plug-in will create a volume and hook the volume up to the appropriate
>> hypervisor. For VMware, this means the plug-in will create a Datastore.
>> For XenServer, this means the plug-in will create a Storage Repository.
>> (So on and so forth for other hypervisors.)
>>
>> * The VM or data disk is then deployed to the hypervisor.
>>
>> Does that sound correct, Edison?
>>
>> Thanks!
>>
>>
>> On Thu, Mar 21, 2013 at 5:44 PM, Edison Su <[email protected]> wrote:
>>
>>> ** **
>>>
>>> ** **
>>>
>>> *From:* Mike Tutkowski [mailto:[email protected]]
>>> *Sent:* Thursday, March 21, 2013 4:18 PM
>>> *To:* Edison Su
>>> *Subject:* Re: Storage Subsystem 2.0 plugin docs****
>>>
>>> ** **
>>>
>>> Hi Edison,****
>>>
>>> ** **
>>>
>>> I wanted to dive into these comments a bit more:****
>>>
>>> ** **
>>>
>>> [Edison] plugin=92s driver->createasync will be called when mgt server w=
> ant
>>> to create a volume on the storage. In the driver=92s implementation, it =
> can
>>> directly call storage box=92s api, or send a command to hypervisor host,=
> then
>>> call storage box=92s api to create an iscsi.****
>>>
>>> Then create a datastore(for vmware), SR(for xenserver), or storage
>>> pool(for KVM) on hypervisor host, based on the iscsi iqn.****
>>>
>>> If the volume is created from a template(for root disk), need to find a
>>> way to import that template(which is nfs based currently, it will be jus=
> t a
>>> plain http url the future) into the root disk.****
>>>
>>> The part about creating a datastore or a storage repository...is that
>>> something the plug-in will be responsible for doing or will the storage
>>> framework cover that piece? I'm thinking the storage framework will sin=
> ce
>>> all sorts of plug-ins would seem to need that ability (to have their
>>> storage hooked up to a datastore or a storage repository).****
>>>
>>> ** **
>>>
>>> [Edison] It=92s a specific requirement for per volume per LUN case, and
>>> specific for certain hypervisors(seems KVM doesn=92t need to create a st=
> orage
>>> pool when using iscsi LUN), so the storage framework will not deal with =
> it
>>> right now.****
>>>
>>> ** **
>>>
>>> ** **
>>>
>>> Thanks for your time, Edison! :)****
> Document new storage subsystem
> ------------------------------
>
> Key: CLOUDSTACK-885
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-885
> Project: CloudStack
> Issue Type: Sub-task
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Doc
> Reporter: Chip Childers
> Fix For: 4.2.0
>
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
