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 17:10:00 GMT
Hey John,

The SolidFire patch does not depend on the object_store branch, but - as
Edison mentioned - it might be easier if we merge the SolidFire branch into
the object_store branch before object_store goes into master.

I'm not sure how the disk_io_throttling fits into this merge strategy.
Perhaps Wei can chime in on that.


On Tue, Jun 11, 2013 at 11:07 AM, John Burwell <jburwell@basho.com> wrote:

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


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