That works. Right now the cmd takes in CHAP info in the form of four strings (initiator username, initiator password, target username, and target password).
I like your idea of a generic list better, though. We could remove the four strings from the cmd and I could use the map in not just KVM land, but Xen and VMware, as well. On Sat, Sep 28, 2013 at 12:28 AM, Marcus Sorensen <shadow...@gmail.com>wrote: > Yeah, maybe we just add a "Map<String, String> connectDetails = > cmd.getConnectDetails()" into attachVolume, and pass that along to > connectPhysicalDisk. Then just set the details where you're currently > setting the chap info prior to the attach command. > > On Sat, Sep 28, 2013 at 12:25 AM, Mike Tutkowski > <mike.tutkow...@solidfire.com> wrote: > > CHAP credentials are per SolidFire/CloudStack account. A volume on the > > SolidFire SAN belongs to an account. I have a one-to-one mapping between > a > > CloudStack account and a SolidFire account. > > > > As far as Volume Access Groups (VAGs) go, I'm not sure what kind of > limits > > they have. > > > > I'd hate to have, say, 10,000 KVM hosts all stuck in the same VAG...each > > host having access (technically) to, say, 20,000 volumes. > > > > VAGs can be created as needed, though...and you can add and remove > > hosts/volumes from them as need be. > > > > On Sat, Sep 28, 2013 at 12:16 AM, Marcus Sorensen <shadow...@gmail.com> > > wrote: > > > >> On Sat, Sep 28, 2013 at 12:09 AM, Mike Tutkowski > >> <mike.tutkow...@solidfire.com> wrote: > >> > Yes, you are correct that our SAN requires CHAP or for the host and > >> volume > >> > to be in a Volume Access Group. > >> > > >> > If CHAP is provided, it is used. If it fails for whatever reason, the > >> > Volume Access Group is NOT leveraged to grant permissions. > >> > > >> > If CHAP is not provided, the host and volume must be in a common > Volume > >> > Access Group. > >> > > >> > As you say, CHAP only grants access...it will not save us from a rouge > >> > compute node that has access to the volume. > >> > >> Ok, I figured the CHAP credentials were predetermined, but it sounds > >> like they're per-lun. > >> > >> > > >> > If we can't get grantAccess and revokeAccess working in the storage > >> > plug-ins for 4.3, I can just use CHAP. I'd prefer to have no SAN calls > >> > coming in from the compute nodes. > >> > >> Yes, we only do it because we have to, but now with the new framework > >> I'm trying to refactor things as they add support for doing things via > >> the plugin. > >> > >> > > >> > Also, I don't think we can grant all hosts in the KVM cluster access > to > >> the > >> > volume ahead of time because the volume won't exist until the first > time > >> we > >> > try to attach it. We have to grant access programmatically. > >> > > >> > Plus you might want to disconnect the volume from a KVM host in one > >> cluster > >> > and connect it up in another KVM cluster (zone-wide storage). > >> > >> I was thinking more along the lines of some group that you'd add your > >> hosts to, regardless of which cluster they're in, as you deploy them. > >> But it sounds like those would need to be done dynamically? i.e. I > >> can't create a group, add a host, and then later add a lun and have > >> access to it? > -- *Mike Tutkowski* *Senior CloudStack Developer, SolidFire Inc.* e: mike.tutkow...@solidfire.com o: 303.746.7302 Advancing the way the world uses the cloud<http://solidfire.com/solution/overview/?video=play> *™*
