Will you be on today's Go to meeting? We can talk about your stuff.
> -----Original Message----- > From: Mike Tutkowski [mailto:mike.tutkow...@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 <jburw...@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.tutkow...@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 <jburw...@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.tutkow...@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.tutkow...@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.tutkow...@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.tutkow...@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.tutkow...@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.tutkow...@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.tutkow...@solidfire.com > o: 303.746.7302 > Advancing the way the world uses the > cloud<http://solidfire.com/solution/overview/?video=play> > *(tm)*
