Return-Path: X-Original-To: apmail-incubator-cloudstack-dev-archive@minotaur.apache.org Delivered-To: apmail-incubator-cloudstack-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 5FFE5DC51 for ; Mon, 11 Mar 2013 19:22:43 +0000 (UTC) Received: (qmail 77082 invoked by uid 500); 11 Mar 2013 19:22:42 -0000 Delivered-To: apmail-incubator-cloudstack-dev-archive@incubator.apache.org Received: (qmail 77036 invoked by uid 500); 11 Mar 2013 19:22:42 -0000 Mailing-List: contact cloudstack-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: cloudstack-dev@incubator.apache.org Delivered-To: mailing list cloudstack-dev@incubator.apache.org Received: (qmail 77028 invoked by uid 99); 11 Mar 2013 19:22:42 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 11 Mar 2013 19:22:42 +0000 X-ASF-Spam-Status: No, hits=2.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_SOFTFAIL X-Spam-Check-By: apache.org Received-SPF: softfail (athena.apache.org: transitioning domain of mike.tutkowski@solidfire.com does not designate 209.85.214.172 as permitted sender) Received: from [209.85.214.172] (HELO mail-ob0-f172.google.com) (209.85.214.172) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 11 Mar 2013 19:22:38 +0000 Received: by mail-ob0-f172.google.com with SMTP id tb18so3733194obb.31 for ; Mon, 11 Mar 2013 12:22:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=OlwnjqQD/yZaKlIhSycbbgsJ8MBIQZm7QBAb5Ae+kos=; b=QLToIx4kbDAfeTEJ5qQfS9QFkor+hXCRMZdK+wDIibABF1dA+MoBwdOn+y7bqdvTUh GB6IASPG3IxsfFOerwCZXGj0N6MDegiyN46FnFvostCyVcGt0d2ZrrzJ8YEvZaSm/Eib TRwH91zt4WCtwcaX1WOa+W6Sj66NfRh326YX4HPqwqEoB4y4QNfiPDw9EnVuF2+Jn+Fy aQyTUyHHzHHkV0p2Mzxt8vaUNCcAEhxnPzc9PsyriHHk+y0qVmlndrl0nUiL/uOIC0e3 Qd25iK3nX+WniCQX1MpuKdZc9CMNrJw5SsVs0Mw+Grkj+rw0ycdRu9/uFD2PPp/1J1Fb 9i9w== MIME-Version: 1.0 X-Received: by 10.60.28.2 with SMTP id x2mr9858520oeg.65.1363029737583; Mon, 11 Mar 2013 12:22:17 -0700 (PDT) Received: by 10.182.76.199 with HTTP; Mon, 11 Mar 2013 12:22:17 -0700 (PDT) In-Reply-To: References: Date: Mon, 11 Mar 2013 13:22:17 -0600 Message-ID: Subject: Re: Storage Subsystem 2.0 Questions From: Mike Tutkowski To: Edison Su Cc: "cloudstack-dev@incubator.apache.org" Content-Type: multipart/alternative; boundary=e89a8ff1c0cc53cdaf04d7ab1710 X-Gm-Message-State: ALoCoQnip4P8CmzNNleLYzr8TjFdUu2tQW+ymJZCNttWndDb+804bThuOZQxlhWzxjmI7XdVbaVs X-Virus-Checked: Checked by ClamAV on apache.org --e89a8ff1c0cc53cdaf04d7ab1710 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 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 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 creat= e > a volume with CHAP credentials when asked to do so, but how do I get thes= e > 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 wan= ts > to access the volume in question? If I have this IQN, I can simply add i= t > to the VAG for the volume. > > > On Mon, Mar 11, 2013 at 11:34 AM, Edison Su 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 th= e >> 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=92s 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 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 t= he >> place to enforce this kind of ACL. How to implement it, it's up to devic= e >> 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, CHA= P >> 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 >> > *(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 >> *=99***** >> >> >> >> **** >> >> ** ** >> >> -- >> *Mike Tutkowski***** >> >> *Senior CloudStack Developer, SolidFire Inc.***** >> >> e: mike.tutkowski@solidfire.com**** >> >> o: 303.746.7302**** >> >> Advancing the way the world uses the cloud >> *=99***** >> > > > > -- > *Mike Tutkowski* > *Senior CloudStack Developer, SolidFire Inc.* > e: mike.tutkowski@solidfire.com > o: 303.746.7302 > Advancing the way the world uses the cloud > *=99* > --=20 *Mike Tutkowski* *Senior CloudStack Developer, SolidFire Inc.* e: mike.tutkowski@solidfire.com o: 303.746.7302 Advancing the way the world uses the cloud *=99* --e89a8ff1c0cc53cdaf04d7ab1710--