You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Mike Tutkowski <mi...@solidfire.com> on 2013/02/05 21:57:45 UTC
Storage Refactor Question
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>
*™*
Re: Storage Refactor Question
Posted by Mike Tutkowski <mi...@solidfire.com>.
I see, Marcus...that makes sense.
Thanks!
On Tue, Feb 5, 2013 at 3:09 PM, Marcus Sorensen <sh...@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
> <mi...@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 <sh...@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
> >> <mi...@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>
*™*
Re: Storage Refactor Question
Posted by Marcus Sorensen <sh...@gmail.com>.
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
<mi...@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 <sh...@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
>> <mi...@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>
> *™*
Re: Storage Refactor Question
Posted by Mike Tutkowski <mi...@solidfire.com>.
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 <sh...@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
> <mi...@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>
*™*
Re: Storage Refactor Question
Posted by Marcus Sorensen <sh...@gmail.com>.
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
<mi...@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>
> *™*