Sure, that sounds good.
On Tue, Jun 11, 2013 at 12:11 PM, Wei ZHOU <ustcweiz...@gmail.com> wrote: > Hi Mike, > > It looks the two feature do not have many conflicts in Java code, except > the cloudstack UI. > If you do not mind, I will merge disk_io_throttling branch into master this > week, so that you can develop based on it. > > -Wei > > > 2013/6/11 Mike Tutkowski <mike.tutkow...@solidfire.com> > > > 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> > > > >> *™* > > > >> > > > > > > > > > > > > > > > > -- > > > > *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> > > > > *™* > > > > > > > > > > > > -- > > *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> > > *™* > > > -- *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> *™*
