cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Tutkowski <mike.tutkow...@solidfire.com>
Subject Re: Storage Subsystem 2.0 Questions
Date Mon, 11 Mar 2013 18:44:00 GMT
Hi Edison,

Thanks for that info.

There are two ways this storage system handles ACLs:  CHAP credentials or
IQNs.

If a host has the proper CHAP credentials for the volume in question, we
allow access to it.

If the host is not using CHAP, then its IQN needs to be in an ACL on the
SAN that we call a Volume Access Group (VAG).

I'm thinking grantAccess might be the proper place for me to get the IQN of
the host that wants to access the volume and put its IQN in the proper VAG
so that it can make use of the volume.

I'm wondering the following:

1) What do I do if CHAP is in use (it will always be in use for our storage
systems running versions lower than 5)?  For example, I can create a volume
with CHAP credentials when asked to do so, but how do I get these CHAP
credentials to the host that wants to access the volume?

2) If CHAP is not in use (it doesn't have to be used for our storage
systems at version 5 or later), how do I get the IQN of the host that wants
to access the volume in question?  If I have this IQN, I can simply add it
to the VAG for the volume.


On Mon, Mar 11, 2013 at 11:34 AM, Edison Su <Edison.su@citrix.com> wrote:

> You can think grantaccess and revokeaccess API are the hookup interfaces
> to your storage plugin. Every time, when cloudstack mgt server wants to
> access the LUN, it will call grantaccess to get the information about the
> LUN, then send down the information to hypervisor host.****
>
> The information returned by grantaccess API, and what you actually do
> inside this API, are up to the implementation. You can do nothing inside
> grantaccess api, but just returns a SR UUID.****
>
> Regarding to CHAP credentials, it’s not really related to grantaccess api.
> Could you tell me, how the CHAP is used in your storage box? ****
>
> ** **
>
> *From:* Mike Tutkowski [mailto:mike.tutkowski@solidfire.com]
> *Sent:* Sunday, March 10, 2013 9:28 PM
> *To:* cloudstack-dev@incubator.apache.org
> *Cc:* Edison Su
> *Subject:* Re: Storage Subsystem 2.0 Questions****
>
> ** **
>
> Hey Edison,****
>
> ** **
>
> Thanks for that info.****
>
> ** **
>
> When grantAccess and revokeAccess are invoked, do I have access to the IQN
> of the host in question?  What about if that host is using CHAP
> credentials?  Where do those come into play?****
>
> ** **
>
> Thanks!****
>
> ** **
>
> On Thu, Mar 7, 2013 at 8:29 PM, Mike Tutkowski <
> mike.tutkowski@solidfire.com> wrote:****
>
> Hey Edison,****
>
> ** **
>
> Thanks for that info.****
>
> ** **
>
> When grantAccess and revokeAccess are invoked, do I have access to the IQN
> of the host in question?  What about if that host is using CHAP
> credentials?  Where do those come into play?****
>
> ** **
>
> Thanks!****
>
> ** **
>
> On Thu, Mar 7, 2013 at 5:36 PM, Edison Su <Edison.su@citrix.com> wrote:***
> *
>
>
>
> > -----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)*****
>
>
>
> ****
>
> ** **
>
> --
> *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>
> *™*****
>
>
>
> ****
>
> ** **
>
> --
> *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>
> *™*****
>



-- 
*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>
*™*

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message