cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Edison Su <Edison...@citrix.com>
Subject RE: [MERGE] disk_io_throttling to MASTER
Date Tue, 11 Jun 2013 17:25:44 GMT
Will you be on today's Go to meeting? We can talk about your stuff.

> -----Original Message-----
> From: Mike Tutkowski [mailto:mike.tutkowski@solidfire.com]
> Sent: Tuesday, June 11, 2013 10:20 AM
> To: dev@cloudstack.apache.org
> Subject: Re: [MERGE] disk_io_throttling to MASTER
> 
> I am OK with it either way.
> 
> Edison, do you still have a preference?
> 
> Thanks!
> 
> 
> On Tue, Jun 11, 2013 at 11:14 AM, John Burwell <jburwell@basho.com>
> wrote:
> 
> > Mike,
> >
> > So my dependency graph below is incorrect.  If there is no dependency
> > between object_store and solidfire, why wouldn't merge them
> > separately?  I ask because the object_store patch is already very
> > large.  As a reviewer try to comprehend the changes, a series of
> > smaller of patches is easier to digest .
> >
> > Thanks,
> > -John
> >
> > On Jun 11, 2013, at 1:10 PM, Mike Tutkowski
> > <mike.tutkowski@solidfire.com>
> > wrote:
> >
> > > 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>
> > >>>> *(tm)*
> > >>>>
> > >>>
> > >>>
> > >>>
> > >>> --
> > >>> *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>
> > >>> *(tm)*
> > >>
> > >>
> > >
> > >
> > > --
> > > *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>
> > > *(tm)*
> >
> >
> 
> 
> --
> *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>
> *(tm)*

Mime
View raw message