Will be the same (from my understanding). Admin will register a primary storage type based on your plugin, with the parameters your storage requires. Then disk offerings that are tagged to match that primary storage. The a user creates volumes referencing the disk offerings.
On Tue, Feb 5, 2013 at 3:01 PM, Mike Tutkowski <[email protected]> wrote: > 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> > *™*
