cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Burwell <>
Subject Re: [MERGE] disk_io_throttling to MASTER
Date Tue, 11 Jun 2013 17:07:46 GMT

We have a delicate merge dance to perform.  The disk_io_throttling, solidfire, and object_store
appear to have a number of overlapping elements.  I understand the dependencies between the
patches to be as follows:

	object_store <- solidfire -> disk_io_throttling

Am I correct that the device management aspects of SolidFire are additive to the object_store
branch or there are circular dependency between the branches?  Once we understand the dependency
graph, we can determine the best approach to land the changes in master.


On Jun 10, 2013, at 11:10 PM, Mike Tutkowski <> wrote:

> Also, if we are good with Edison merging my code into his branch before
> going into master, I am good with that.
> We can remove the StoragePoolType.Dynamic code after his merge and we can
> deal with Burst IOPS then, as well.
> On Mon, Jun 10, 2013 at 9:08 PM, Mike Tutkowski <
>> wrote:
>> 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 <
>>> 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:
>> o: 303.746.7302
>> Advancing the way the world uses the cloud<>
>> *™*
> -- 
> *Mike Tutkowski*
> *Senior CloudStack Developer, SolidFire Inc.*
> e:
> o: 303.746.7302
> Advancing the way the world uses the
> cloud<>
> *™*

View raw message