incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Edison Su <Edison...@citrix.com>
Subject RE: Storage Subsystem 2.0 Questions
Date Fri, 08 Mar 2013 00:36:31 GMT


> -----Original Message-----
> From: Mike Tutkowski [mailto:mike.tutkowski@solidfire.com]
> Sent: Monday, March 04, 2013 9:22 PM
> To: cloudstack-dev@incubator.apache.org
> Subject: Storage Subsystem 2.0 Questions
> 
> Hi,
> 
> I'm working on implementing a storage plug-in for CS 4.2.
> 
> I'm looking at the following Wiki page for guidance, but have some
> questions:
> 
> https://cwiki.apache.org/CLOUDSTACK/storage-subsystem-20.html
> 
> One interface that needs to be implemented is PrimaryDataStoreDriver.  I'm
> not sure what is expected for all of the following methods:
> 
> * grantAccess:  It looks like this is called in an attempt to confirm that the host
> which desires access to the volume in question is allowed to do so.  I suspect
> this is where CHAP credentials might be provided?  In my situation, there are
> a couple ways I'd like to restrict access:  1) CHAP or
> 2) allow a subset of IQNs to access the volume in question.  Is this kind of
> information provided to me here?  Do I simply return the IQN of the volume
> as a successful response from this method?  What if the access sent is not
> sufficient?  How do I deny access?
In the original design, it has two purposes: 
1. Make the volume accessible to a storage client(e.g. a hypervisor host who wants to access
this volume). If the storage box has its ACL, it's the place to enforce this kind of ACL.
How to implement it, it's up to device vendor. For example, when creating a volume, I make
it inaccessible to anybody, later on, when cloudstack selects an hypervisor host to access
this volume(e.g attach the volume to VM created on this hypervisor host), cloudstack will
call this API to make the volume accessible to this hypervisor host. 
It's not exactly the same as CHAP credentials. Per my understanding, CHAP credential is an
access token, it already implies, anybody who has this credential, can access this volume.
You can think this API as the way to generate this token.
2. Return a string to represent the volume, either an IQN, or uuid, or IQN + CHAP credentials,
or an URI, etc, cloudstack will send down the string to hypervisor host, in order to access
the volume.

> 
> * revokeAccess:  I don't really understand when this method would be called
> or why.  Perhaps I can simply implement it to return true (or false)?  In my
> situation, when a volume is dynamically created for a hypervisor of a cluster,
> I'd want to allow access to it from all hosts in the app cluster in question.
> Maybe this method is called before the volume is deleted or something?

It's the reverse step as grantaccess. Whatever you did in grantaccess should be reversed in
this API.

> 
> * listObjects:  I don't really understand when this method would be called or
> why.


This is the API to list existing volumes on the storage box. The usage case will be able to
import existing volumes/templates into cloudstack, if the DB is wiped out.
You can don't implement it as nobody uses it yet.

> 
> * createAsync:  I believe this is where I place my code to create a volume
> (LUN) on our SAN.
> 
> * deleteAsync:  I believe this is where I place my code to delete a volume
> (LUN) on our SAN.
> 
> Thanks for any guidance here!
> 
> --
> *Mike Tutkowski*
> *Senior CloudStack Developer, SolidFire Inc.*
> e: mike.tutkowski@solidfire.com
> o: 303.746.7302
> Advancing the way the world uses the
> cloud<http://solidfire.com/solution/overview/?video=play>
> *(tm)*

Mime
View raw message