I see, Marcus...that makes sense. Thanks!
On Tue, Feb 5, 2013 at 3:09 PM, Marcus Sorensen <[email protected]> wrote: > 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> > > *™* > -- *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> *™*
