You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@cloudstack.apache.org by Mike Tutkowski <mi...@solidfire.com> on 2013/03/05 06:21:57 UTC

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?

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

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

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

Re: Storage Subsystem 2.0 Questions

Posted by Mike Tutkowski <mi...@solidfire.com>.

I'm looking at the following for documentation, by the way, but please let
me know if there are additional resources to review:

https://cwiki.apache.org/CLOUDSTACK/storage-subsystem-20.html

What I could really use is sequence diagram that starts with a user kicking
off a Compute or Disk Offering that's based on a Primary Storage that makes
use of a plug-in and how the calls I implement in the plug-in get invoked
(in what order).

That would be awesome.  :)


On Mon, Mar 11, 2013 at 1:45 PM, Mike Tutkowski <
mike.tutkowski@solidfire.com> wrote:

> Looking at this a bit more, I'm thinking DataObject represents the
> volume/LUN (for me) and EndPoint is the host?
>
> Let's use XenServer as an example.
>
> The user kicks off a Compute Offering that is based on a Primary Storage
> that uses my plug-in.
>
> The createAsync method is invoked and this is where I create my volume/LUN
> on the SAN and return an IQN.  At this point, I do not have any IQNs in the
> Volume Access Group (VAG).  Remember that if CHAP is not in use, then IQNs
> that want to access this volume need to be in this VAG.  If CHAP is in use,
> then the credentials exist on the SAN, but have not been placed on any host
> yet.
>
> At what point will the Storage Repository for XenServer be created (and
> based on my iSCSI target)?  This must happen after createAsync is called
> and before grantAccess?
>
> Perhaps you can clarify this, Edison?
>
> Thanks!
>
>
> On Mon, Mar 11, 2013 at 1:22 PM, Mike Tutkowski <
> mike.tutkowski@solidfire.com> wrote:
>
>> As an example, in grantAccess, I'm passed in a DataObject.
>>
>> public interface DataObject {
>>
>>     public long getId();
>>
>>     public String getUri();
>>
>>     public DataStore getDataStore();
>>
>>     public Long getSize();
>>
>>     public DataObjectType getType();
>>
>>     public DiskFormat getFormat();
>>
>>     public String getUuid();
>>
>>     public void processEvent(ObjectInDataStoreStateMachine.Event event);
>>
>> }
>>
>>
>> Can you tell me what this object represents in this context?  Is it the
>> host that wants to access the volume?
>>
>> Is there somewhere I can go to find out what each of these "get" methods
>> returns to me?
>>
>> Same basic question about the EndPoint interface.
>>
>>     public interface EndPoint {
>>
>>     public long getId();
>>
>>     public Answer sendMessage(Command cmd);
>>
>>     public void sendMessageAsync(Command cmd,
>> AsyncCompletionCallback<Answer> callback);
>>
>> }
>>
>> Thanks!
>>
>>
>> On Mon, Mar 11, 2013 at 12:44 PM, Mike Tutkowski <
>> mike.tutkowski@solidfire.com> wrote:
>>
>>> 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 <Ed...@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 <Ed...@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>
>>> *™*
>>>
>>
>>
>>
>> --
>> *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>
*™*

Re: Storage Subsystem 2.0 Questions

Posted by Mike Tutkowski <mi...@solidfire.com>.

Looking at this a bit more, I'm thinking DataObject represents the
volume/LUN (for me) and EndPoint is the host?

Let's use XenServer as an example.

The user kicks off a Compute Offering that is based on a Primary Storage
that uses my plug-in.

The createAsync method is invoked and this is where I create my volume/LUN
on the SAN and return an IQN.  At this point, I do not have any IQNs in the
Volume Access Group (VAG).  Remember that if CHAP is not in use, then IQNs
that want to access this volume need to be in this VAG.  If CHAP is in use,
then the credentials exist on the SAN, but have not been placed on any host
yet.

At what point will the Storage Repository for XenServer be created (and
based on my iSCSI target)?  This must happen after createAsync is called
and before grantAccess?

Perhaps you can clarify this, Edison?

Thanks!


On Mon, Mar 11, 2013 at 1:22 PM, Mike Tutkowski <
mike.tutkowski@solidfire.com> wrote:

> As an example, in grantAccess, I'm passed in a DataObject.
>
> public interface DataObject {
>
>     public long getId();
>
>     public String getUri();
>
>     public DataStore getDataStore();
>
>     public Long getSize();
>
>     public DataObjectType getType();
>
>     public DiskFormat getFormat();
>
>     public String getUuid();
>
>     public void processEvent(ObjectInDataStoreStateMachine.Event event);
>
> }
>
>
> Can you tell me what this object represents in this context?  Is it the
> host that wants to access the volume?
>
> Is there somewhere I can go to find out what each of these "get" methods
> returns to me?
>
> Same basic question about the EndPoint interface.
>
>     public interface EndPoint {
>
>     public long getId();
>
>     public Answer sendMessage(Command cmd);
>
>     public void sendMessageAsync(Command cmd,
> AsyncCompletionCallback<Answer> callback);
>
> }
>
> Thanks!
>
>
> On Mon, Mar 11, 2013 at 12:44 PM, Mike Tutkowski <
> mike.tutkowski@solidfire.com> wrote:
>
>> 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 <Ed...@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 <Ed...@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>
>> *™*
>>
>
>
>
> --
> *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>
*™*

Re: Storage Subsystem 2.0 Questions

Posted by Mike Tutkowski <mi...@solidfire.com>.

As an example, in grantAccess, I'm passed in a DataObject.

public interface DataObject {

    public long getId();

    public String getUri();

    public DataStore getDataStore();

    public Long getSize();

    public DataObjectType getType();

    public DiskFormat getFormat();

    public String getUuid();

    public void processEvent(ObjectInDataStoreStateMachine.Event event);

}


Can you tell me what this object represents in this context?  Is it the
host that wants to access the volume?

Is there somewhere I can go to find out what each of these "get" methods
returns to me?

Same basic question about the EndPoint interface.

    public interface EndPoint {

    public long getId();

    public Answer sendMessage(Command cmd);

    public void sendMessageAsync(Command cmd,
AsyncCompletionCallback<Answer> callback);

}

Thanks!


On Mon, Mar 11, 2013 at 12:44 PM, Mike Tutkowski <
mike.tutkowski@solidfire.com> wrote:

> 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 <Ed...@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 <Ed...@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>
> *™*
>



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

Re: Storage Subsystem 2.0 Questions

Posted by Mike Tutkowski <mi...@solidfire.com>.

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 <Ed...@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 <Ed...@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>
*™*

RE: Storage Subsystem 2.0 Questions

Posted by Edison Su <Ed...@citrix.com>.

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 <mi...@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 <Ed...@citrix.com>> wrote:


> -----Original Message-----
> From: Mike Tutkowski [mailto:mike.tutkowski@solidfire.com<ma...@solidfire.com>]
> Sent: Monday, March 04, 2013 9:22 PM
> To: cloudstack-dev@incubator.apache.org<ma...@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<ma...@solidfire.com>
> o: 303.746.7302<tel: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<ma...@solidfire.com>
o: 303.746.7302<tel: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<ma...@solidfire.com>
o: 303.746.7302
Advancing the way the world uses the cloud<http://solidfire.com/solution/overview/?video=play>(tm)

Re: Storage Subsystem 2.0 Questions

Posted by Mike Tutkowski <mi...@solidfire.com>.

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 <Ed...@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>
*™*

Re: Storage Subsystem 2.0 Questions

Posted by Mike Tutkowski <mi...@solidfire.com>.

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 <Ed...@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>
*™*

RE: Storage Subsystem 2.0 Questions

Posted by Edison Su <Ed...@citrix.com>.


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

Re: Storage Subsystem 2.0 Questions

Posted by Mike Tutkowski <mi...@solidfire.com>.

On a related note, it looks like the scope of Primary Storage has changed
in 4.2.  What are the benefits of this scoping feature?  For example, does
it help mainly if you want to migrate a VM from one cluster to another?

Thanks


On Tue, Mar 5, 2013 at 10:56 AM, Mike Tutkowski <
mike.tutkowski@solidfire.com> wrote:

> Thanks, Marcus
>
> When Edison sees this e-mail chain, he will be able to fill in extra
> details.
>
>
> On Mon, Mar 4, 2013 at 11:08 PM, Marcus Sorensen <sh...@gmail.com>wrote:
>
>>  Generally the targets I've worked with support different levels of
>> access control, so you may have a high level block where you can't
>> even see the target unless you come from the right IP (ACL/firewall),
>> then you've got something like CHAP, and then maybe the target
>> supports persistent reservations so that only one client can use a
>> given LUN at any one time. It's a combination of the client software
>> expects and what the target offers that ensures integrity.
>>
>> I should probably let someone else who has more insight into the
>> storage 2.0 specific stuff clarify your questions, since I'm not 100%
>> certain what those methods are intended for.
>>
>> On Mon, Mar 4, 2013 at 10:55 PM, Mike Tutkowski
>> <mi...@solidfire.com> wrote:
>> > Interesting, Marcus...thanks for the comments.
>> >
>> > Yeah, the way it works on our SAN is a given volume is either accessible
>> > via CHAP credentials or - if CHAP is not being used - a set of IQNs is
>> > maintained and any initiator with a "proper" IQN can access the volume
>> (we
>> > depend on client-side software to be smart enough to not corrupt the
>> state
>> > of a volume).
>> >
>> > I wonder what you recommend in this situation?
>> >
>> > Thanks!
>> >
>> >
>> > On Mon, Mar 4, 2013 at 10:45 PM, Marcus Sorensen <shadowsor@gmail.com
>> >wrote:
>> >
>> >> On Mon, Mar 4, 2013 at 10:41 PM, Marcus Sorensen <sh...@gmail.com>
>> >> wrote:
>> >> > On revoke/grant access, If we're talking about individual volumes
>> >> > being equal to a data/root disk, it's wise to adjust ACLs to only
>> >> > allow access to the host that is currently wanting to run the
>> VM/disk.
>> >> > This way, cloudstack is authoritative in what's accessing the lun,
>> and
>> >> > you don't have to run a separate cluster/locking daemon. Otherwise,
>> if
>> >> > you launch a VM on a host, and that host goes rogue (loses some sort
>> >> > of connectivity, but the vm remains running and connected to the
>> >> > storage), when cloudstack tries to start that VM elsewhere then the
>> >> > access to storage is cut off from the original VM. Having the same VM
>> >> > running twice, connected to the same disk image, is a bad thing :-)
>> >> >
>> >> > In other words, before you start a VM or attach a disk, you'd revoke
>> >> > access to everyone, then grant access to the host you're running the
>> >> > VM/disk on.
>> >>
>> >> **disclaimer - I haven't done more than a cursory look at the storage
>> >> 2.0 stuff, so what I'm saying might not even apply to what you're
>> >> looking at now, but you probably should implement revokeAccess to
>> >> remove ACLs based on the parameters passed.
>> >>
>> >> >
>> >> > On Mon, Mar 4, 2013 at 10:21 PM, Mike Tutkowski
>> >> > <mi...@solidfire.com> wrote:
>> >> >> 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?
>> >> >>
>> >> >> * 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?
>> >> >>
>> >> >> * listObjects:  I don't really understand when this method would be
>> >> called
>> >> >> or why.
>> >> >>
>> >> >> * 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>
>> >> >> *™*
>> >>
>> >
>> >
>> >
>> > --
>> > *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>
*™*

Re: Storage Subsystem 2.0 Questions

Posted by Mike Tutkowski <mi...@solidfire.com>.

Thanks, Marcus

When Edison sees this e-mail chain, he will be able to fill in extra
details.


On Mon, Mar 4, 2013 at 11:08 PM, Marcus Sorensen <sh...@gmail.com>wrote:

>  Generally the targets I've worked with support different levels of
> access control, so you may have a high level block where you can't
> even see the target unless you come from the right IP (ACL/firewall),
> then you've got something like CHAP, and then maybe the target
> supports persistent reservations so that only one client can use a
> given LUN at any one time. It's a combination of the client software
> expects and what the target offers that ensures integrity.
>
> I should probably let someone else who has more insight into the
> storage 2.0 specific stuff clarify your questions, since I'm not 100%
> certain what those methods are intended for.
>
> On Mon, Mar 4, 2013 at 10:55 PM, Mike Tutkowski
> <mi...@solidfire.com> wrote:
> > Interesting, Marcus...thanks for the comments.
> >
> > Yeah, the way it works on our SAN is a given volume is either accessible
> > via CHAP credentials or - if CHAP is not being used - a set of IQNs is
> > maintained and any initiator with a "proper" IQN can access the volume
> (we
> > depend on client-side software to be smart enough to not corrupt the
> state
> > of a volume).
> >
> > I wonder what you recommend in this situation?
> >
> > Thanks!
> >
> >
> > On Mon, Mar 4, 2013 at 10:45 PM, Marcus Sorensen <shadowsor@gmail.com
> >wrote:
> >
> >> On Mon, Mar 4, 2013 at 10:41 PM, Marcus Sorensen <sh...@gmail.com>
> >> wrote:
> >> > On revoke/grant access, If we're talking about individual volumes
> >> > being equal to a data/root disk, it's wise to adjust ACLs to only
> >> > allow access to the host that is currently wanting to run the VM/disk.
> >> > This way, cloudstack is authoritative in what's accessing the lun, and
> >> > you don't have to run a separate cluster/locking daemon. Otherwise, if
> >> > you launch a VM on a host, and that host goes rogue (loses some sort
> >> > of connectivity, but the vm remains running and connected to the
> >> > storage), when cloudstack tries to start that VM elsewhere then the
> >> > access to storage is cut off from the original VM. Having the same VM
> >> > running twice, connected to the same disk image, is a bad thing :-)
> >> >
> >> > In other words, before you start a VM or attach a disk, you'd revoke
> >> > access to everyone, then grant access to the host you're running the
> >> > VM/disk on.
> >>
> >> **disclaimer - I haven't done more than a cursory look at the storage
> >> 2.0 stuff, so what I'm saying might not even apply to what you're
> >> looking at now, but you probably should implement revokeAccess to
> >> remove ACLs based on the parameters passed.
> >>
> >> >
> >> > On Mon, Mar 4, 2013 at 10:21 PM, Mike Tutkowski
> >> > <mi...@solidfire.com> wrote:
> >> >> 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?
> >> >>
> >> >> * 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?
> >> >>
> >> >> * listObjects:  I don't really understand when this method would be
> >> called
> >> >> or why.
> >> >>
> >> >> * 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>
> >> >> *™*
> >>
> >
> >
> >
> > --
> > *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>
*™*

Re: Storage Subsystem 2.0 Questions

Posted by Marcus Sorensen <sh...@gmail.com>.

 Generally the targets I've worked with support different levels of
access control, so you may have a high level block where you can't
even see the target unless you come from the right IP (ACL/firewall),
then you've got something like CHAP, and then maybe the target
supports persistent reservations so that only one client can use a
given LUN at any one time. It's a combination of the client software
expects and what the target offers that ensures integrity.

I should probably let someone else who has more insight into the
storage 2.0 specific stuff clarify your questions, since I'm not 100%
certain what those methods are intended for.

On Mon, Mar 4, 2013 at 10:55 PM, Mike Tutkowski
<mi...@solidfire.com> wrote:
> Interesting, Marcus...thanks for the comments.
>
> Yeah, the way it works on our SAN is a given volume is either accessible
> via CHAP credentials or - if CHAP is not being used - a set of IQNs is
> maintained and any initiator with a "proper" IQN can access the volume (we
> depend on client-side software to be smart enough to not corrupt the state
> of a volume).
>
> I wonder what you recommend in this situation?
>
> Thanks!
>
>
> On Mon, Mar 4, 2013 at 10:45 PM, Marcus Sorensen <sh...@gmail.com>wrote:
>
>> On Mon, Mar 4, 2013 at 10:41 PM, Marcus Sorensen <sh...@gmail.com>
>> wrote:
>> > On revoke/grant access, If we're talking about individual volumes
>> > being equal to a data/root disk, it's wise to adjust ACLs to only
>> > allow access to the host that is currently wanting to run the VM/disk.
>> > This way, cloudstack is authoritative in what's accessing the lun, and
>> > you don't have to run a separate cluster/locking daemon. Otherwise, if
>> > you launch a VM on a host, and that host goes rogue (loses some sort
>> > of connectivity, but the vm remains running and connected to the
>> > storage), when cloudstack tries to start that VM elsewhere then the
>> > access to storage is cut off from the original VM. Having the same VM
>> > running twice, connected to the same disk image, is a bad thing :-)
>> >
>> > In other words, before you start a VM or attach a disk, you'd revoke
>> > access to everyone, then grant access to the host you're running the
>> > VM/disk on.
>>
>> **disclaimer - I haven't done more than a cursory look at the storage
>> 2.0 stuff, so what I'm saying might not even apply to what you're
>> looking at now, but you probably should implement revokeAccess to
>> remove ACLs based on the parameters passed.
>>
>> >
>> > On Mon, Mar 4, 2013 at 10:21 PM, Mike Tutkowski
>> > <mi...@solidfire.com> wrote:
>> >> 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?
>> >>
>> >> * 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?
>> >>
>> >> * listObjects:  I don't really understand when this method would be
>> called
>> >> or why.
>> >>
>> >> * 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>
>> >> *™*
>>
>
>
>
> --
> *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>
> *™*

Re: Storage Subsystem 2.0 Questions

Posted by Mike Tutkowski <mi...@solidfire.com>.

Interesting, Marcus...thanks for the comments.

Yeah, the way it works on our SAN is a given volume is either accessible
via CHAP credentials or - if CHAP is not being used - a set of IQNs is
maintained and any initiator with a "proper" IQN can access the volume (we
depend on client-side software to be smart enough to not corrupt the state
of a volume).

I wonder what you recommend in this situation?

Thanks!


On Mon, Mar 4, 2013 at 10:45 PM, Marcus Sorensen <sh...@gmail.com>wrote:

> On Mon, Mar 4, 2013 at 10:41 PM, Marcus Sorensen <sh...@gmail.com>
> wrote:
> > On revoke/grant access, If we're talking about individual volumes
> > being equal to a data/root disk, it's wise to adjust ACLs to only
> > allow access to the host that is currently wanting to run the VM/disk.
> > This way, cloudstack is authoritative in what's accessing the lun, and
> > you don't have to run a separate cluster/locking daemon. Otherwise, if
> > you launch a VM on a host, and that host goes rogue (loses some sort
> > of connectivity, but the vm remains running and connected to the
> > storage), when cloudstack tries to start that VM elsewhere then the
> > access to storage is cut off from the original VM. Having the same VM
> > running twice, connected to the same disk image, is a bad thing :-)
> >
> > In other words, before you start a VM or attach a disk, you'd revoke
> > access to everyone, then grant access to the host you're running the
> > VM/disk on.
>
> **disclaimer - I haven't done more than a cursory look at the storage
> 2.0 stuff, so what I'm saying might not even apply to what you're
> looking at now, but you probably should implement revokeAccess to
> remove ACLs based on the parameters passed.
>
> >
> > On Mon, Mar 4, 2013 at 10:21 PM, Mike Tutkowski
> > <mi...@solidfire.com> wrote:
> >> 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?
> >>
> >> * 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?
> >>
> >> * listObjects:  I don't really understand when this method would be
> called
> >> or why.
> >>
> >> * 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>
> >> *™*
>



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

Re: Storage Subsystem 2.0 Questions

Posted by Marcus Sorensen <sh...@gmail.com>.

On Mon, Mar 4, 2013 at 10:41 PM, Marcus Sorensen <sh...@gmail.com> wrote:
> On revoke/grant access, If we're talking about individual volumes
> being equal to a data/root disk, it's wise to adjust ACLs to only
> allow access to the host that is currently wanting to run the VM/disk.
> This way, cloudstack is authoritative in what's accessing the lun, and
> you don't have to run a separate cluster/locking daemon. Otherwise, if
> you launch a VM on a host, and that host goes rogue (loses some sort
> of connectivity, but the vm remains running and connected to the
> storage), when cloudstack tries to start that VM elsewhere then the
> access to storage is cut off from the original VM. Having the same VM
> running twice, connected to the same disk image, is a bad thing :-)
>
> In other words, before you start a VM or attach a disk, you'd revoke
> access to everyone, then grant access to the host you're running the
> VM/disk on.

**disclaimer - I haven't done more than a cursory look at the storage
2.0 stuff, so what I'm saying might not even apply to what you're
looking at now, but you probably should implement revokeAccess to
remove ACLs based on the parameters passed.

>
> On Mon, Mar 4, 2013 at 10:21 PM, Mike Tutkowski
> <mi...@solidfire.com> wrote:
>> 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?
>>
>> * 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?
>>
>> * listObjects:  I don't really understand when this method would be called
>> or why.
>>
>> * 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>
>> *™*

Re: Storage Subsystem 2.0 Questions

Posted by Marcus Sorensen <sh...@gmail.com>.

On revoke/grant access, If we're talking about individual volumes
being equal to a data/root disk, it's wise to adjust ACLs to only
allow access to the host that is currently wanting to run the VM/disk.
This way, cloudstack is authoritative in what's accessing the lun, and
you don't have to run a separate cluster/locking daemon. Otherwise, if
you launch a VM on a host, and that host goes rogue (loses some sort
of connectivity, but the vm remains running and connected to the
storage), when cloudstack tries to start that VM elsewhere then the
access to storage is cut off from the original VM. Having the same VM
running twice, connected to the same disk image, is a bad thing :-)

In other words, before you start a VM or attach a disk, you'd revoke
access to everyone, then grant access to the host you're running the
VM/disk on.

On Mon, Mar 4, 2013 at 10:21 PM, Mike Tutkowski
<mi...@solidfire.com> wrote:
> 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?
>
> * 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?
>
> * listObjects:  I don't really understand when this method would be called
> or why.
>
> * 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>
> *™*