cloudstack-dev mailing list archives

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

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.

Thanks,
-John


On Jun 10, 2013, at 11:10 PM, Mike Tutkowski <mike.tutkowski@solidfire.com> 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 <
> mike.tutkowski@solidfire.com> 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 <
>> 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>
>> *™*
>> 
> 
> 
> 
> -- 
> *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
View raw message