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: [MERGE] disk_io_throttling to MASTER
Date Tue, 11 Jun 2013 03:08:57 GMT
Let me make sure I follow where we're going here:

1) There should be NO references to hypervisor code in the storage plug-ins
code (this includes the default storage plug-in, which currently sends
several commands to the hypervisor in use (although it does not know which
hypervisor (XenServer, ESX(i), etc.) is actually in use))

2) managed=true or managed=false can be placed in the url field (if not
present, we default to false). This info is stored in the
storage_pool_details table.

3) When the "attach" command is sent to the hypervisor in question, we pass
the managed property along (this takes the place of the
StoragePoolType.Dynamic check).

4) execute(AttachVolumeCommand) in the hypervisor checks for the managed
property. If true for an attach, the necessary hypervisor data structure is
created and the rest of the attach command executes to attach the volume.

5) When execute(AttachVolumeCommand) is invoked to detach a volume, the
same check is made. If managed, the hypervisor data structure is removed.

6) I do not see an clear way to support Burst IOPS in 4.2 unless it is
stored in the volumes and disk_offerings table. If we have some idea,
that'd be cool.

Thanks!


On Mon, Jun 10, 2013 at 8:58 PM, Mike Tutkowski <
mike.tutkowski@solidfire.com> wrote:

> "+1 -- Burst IOPS can be implemented while avoiding implementation
> attributes.  I always wondered about the details field.  I think we should
> beef up the description in the documentation regarding the expected format
> of the field.  In 4.1, I noticed that the details are not returned on the
> createStoratePool updateStoragePool, or listStoragePool response.  Why
> don't we return it?  It seems like it would be useful for clients to be
> able to inspect the contents of the details field."
>
> Not sure how this would work storing Burst IOPS here.
>
> Burst IOPS need to be variable on a Disk Offering-by-Disk Offering basis.
> For each Disk Offering created, you have to be able to associate unique
> Burst IOPS. There is a disk_offering_details table. Maybe it could go there?
>
> I'm also not sure how you would accept the Burst IOPS in the GUI if it's
> not stored like the Min and Max fields are in the DB.
>



-- 
*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