incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Tutkowski <mike.tutkow...@solidfire.com>
Subject Re: Storage Refactor Question
Date Tue, 05 Feb 2013 22:28:13 GMT
I see, Marcus...that makes sense.

Thanks!


On Tue, Feb 5, 2013 at 3:09 PM, Marcus Sorensen <shadowsor@gmail.com> 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
> <mike.tutkowski@solidfire.com> 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 <shadowsor@gmail.com>
> 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
> >> <mike.tutkowski@solidfire.com> 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: mike.tutkowski@solidfire.com
> >> > 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: mike.tutkowski@solidfire.com
> > 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: mike.tutkowski@solidfire.com
o: 303.746.7302
Advancing the way the world uses the
cloud<http://solidfire.com/solution/overview/?video=play>
*™*

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message