Thanks, Marcus I'm working on a plug-in right now (for SolidFire). I've been following some sample code and looking at https://cwiki.apache.org/confluence/display/CLOUDSTACK/Storage+subsystem+2.0#Storagesubsystem2.0-Whichinterfacesshouldbeimplementedbydevicedriverdeveloper%3F .
I haven't gotten anything up and running yet, but I was curious what to expect when the time came. It sounds like existing behavior will remain in place (regarding Primary Storage types). So, when a user wants to create a Compute or Disk Offering based on storage provided by my plug-in, how does the admin set things up so that works? Right now, the admin would use a Storage Tag to reference one or more Primary Storage types. Do you know how the admin will create the association with storage provided by my plug-in? Thanks! On Tue, Feb 5, 2013 at 2:51 PM, Marcus Sorensen <[email protected]> wrote: > The flow should be identical from a user's point of view. The > implementation depends on the primary storage. For example, the > existing methods/primary storage types will continue to work the same, > no change from a user's perspective, except for more storage options > as plugins are created. > > What changes in the code is that instead of passing a CreateCommand to > the VM host to create a qcow2 file, a vhd, a logical volume, or > whatever constitutes a 'disk' per your primary storage implementation, > it talks to a new Volume Service that calls your primary storage > handler. It may do the same thing it did before (in the case of > existing storage types), or it may go carve out a LUN on the SAN, or > whatever you define. This cleans up some of the issues around > if..elseif...elseif...elseif for every storage type. > > You can certainly implement yet another primary storage type in the > current code. Then when the refactor comes along you can fix it up, > but either way the flow will be the same from the user. > > On Tue, Feb 5, 2013 at 1:57 PM, Mike Tutkowski > <[email protected]> wrote: > > Hi everyone, > > > > Edison has been working on enhancing CloudStack's storage component for > > some time now. > > > > One of the improvements is to no longer require large amounts of storage > to > > be provisioned upfront. It's my understanding that with his changes you > > can dynamically create a storage volume (a single LUN) to run a VM on or > to > > serve as a data disk. > > > > My question is how this works from a user's point of view. Does anyone > > have any insight into this? > > > > For example, today the admin creates a Primary Storage type ahead of the > > user needing to use it. The admin then associates it with a Compute > and/or > > a Disk Offering. The user later elects to make use of a given Compute > > and/or Disk Offering. > > > > I'm curious how the flow will be with storage being dynamically allocated > > when a user needs it. > > > > Thanks! > > > > -- > > *Mike Tutkowski* > > *Senior CloudStack Developer, SolidFire Inc.* > > e: [email protected] > > 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: [email protected] o: 303.746.7302 Advancing the way the world uses the cloud<http://solidfire.com/solution/overview/?video=play> *™*
