Mike, Glad to see this. This is what I have questioned about.
I accepted John's and your opnion that hypervisor IOPS and storage IOPS are mutually exclusion. The way you mentioned is a good way to go. A small question is, will burst IOPS only appear when storage device is SolidFire? -Wei 2013/6/10 Mike Tutkowski <mike.tutkow...@solidfire.com> > My thinking is that Min and Max are industry standard and Burst is a new > concept that could catch on. > > > On Mon, Jun 10, 2013 at 2:29 PM, John Burwell <jburw...@basho.com> wrote: > > > Wei, > > > > In this case, we can have the hypervisor or storage providing the quality > > of service guarantee. Naively, it seems reasonable to separate > hypervisor > > and storage QoS parameters and enforce mutually exclusion. Not only does > > this approach simplify a whole range of operations, it also avoids > > reconciling the data models. The only question I have about the storage > > provision IOPS is whether or not "Burst IOPS" is an industry standard or > > vendor specific concept. > > > > Thanks, > > -John > > > > On Jun 10, 2013, at 3:59 PM, Wei ZHOU <ustcweiz...@gmail.com> wrote: > > > > > Mike, > > > I do not think users can select only one of them, as they are > implemented > > > on different sides. > > > Have you investigated the parameters other storage devices support, > > besides > > > min/max/burst IOPS? You'd better add all possible fields in your > > > implementation. > > > > > > What do you think about this? > > > Hypersivor IOPS is fixed, and there is a drop-down box which includes > all > > > supported storage vendors. > > > If users select "SolidFire", min/max/burst IOPS will appear. > > > If users select other vendors, relevant fields will appear. > > > Actually I still insist that it is better to add the storage-related > > fields > > > in another table. > > > > > > -Wei > > > > > > > > > 2013/6/10 Mike Tutkowski <mike.tutkow...@solidfire.com> > > > > > >> Here is my thinking: > > >> > > >> Two radio buttons (whatever we want to call them): > > >> > > >> 1) Hypervisor IOPS > > >> 2) Storage IOPS > > >> > > >> Leave them both un-checked by default. > > >> > > >> If the user checks one or the other, the relevant fields appear. > > >> > > >> > > >> On Mon, Jun 10, 2013 at 1:38 PM, Mike Tutkowski < > > >> mike.tutkow...@solidfire.com> wrote: > > >> > > >>> What do you think, Wei? > > >>> > > >>> Should we come up with a way for only one feature (yours or mine) to > be > > >>> used at a time on the new Disk Offering dialog? > > >>> > > >>> Since most storage-side provisioned IOPS don't break it down into > > >> separate > > >>> read and write categories, I think that's the way to go (only one > > feature > > >>> or the other). > > >>> > > >>> Any suggestions from a usability standpoint how we want to implement > > >> this? > > >>> It could be as simple as a radio button to turn on your feature and > > mine > > >>> off or vice versa. > > >>> > > >>> Thanks! > > >>> > > >>> > > >>> On Mon, Jun 10, 2013 at 1:33 PM, John Burwell <jburw...@basho.com> > > >> wrote: > > >>> > > >>>> Mike, > > >>>> > > >>>> I agree -- I can't image a situation where you would want to use > IOPS > > >>>> provisioned by both the hypervisor and storage. There are two > points > > of > > >>>> concern -- the UI and the management server. We have to ensure that > > the > > >>>> user can't create a VM from a compute/disk offering combination > where > > >>>> hypervisor throttled I/O would contradict/conflict with storage > > >> provisioned > > >>>> IOPS. I think this functional conflict must be resolved in the > > >> management > > >>>> server to ensure that API calls are properly validated with a UX > that > > >>>> avoids user confusion. Have Wei and you worked out an approach to > > >>>> resolving this conflict? > > >>>> > > >>>> Thanks, > > >>>> -John > > >>>> > > >>>> On Jun 10, 2013, at 3:24 PM, Mike Tutkowski < > > >> mike.tutkow...@solidfire.com> > > >>>> wrote: > > >>>> > > >>>>> Wei has sent me the screen shots. > > >>>>> > > >>>>> I don't support Compute Offerings for 4.2, so that's not an issue > > >> here. > > >>>>> > > >>>>> I do support Disk Offerings. > > >>>>> > > >>>>> It looks like Wei has added four new fields to the Disk Offering. > > >>>>> > > >>>>> I have added three (Min, Max, and Burst IOPS). > > >>>>> > > >>>>> We just need to decide if we should toggle between his and mine. > > >>>>> > > >>>>> I doubt a user would want to use both features at the same time. > > >>>>> > > >>>>> > > >>>>> On Mon, Jun 10, 2013 at 12:30 PM, John Burwell <jburw...@basho.com > > > > >>>> wrote: > > >>>>> > > >>>>>> Mike, > > >>>>>> > > >>>>>> Have Wei and you figured out the system level as well (e.g. > allowing > > >>>>>> either storage provisioned IOPS or hypervisor throttling, but no > > >> both)? > > >>>>>> > > >>>>>> Thanks, > > >>>>>> -John > > >>>>>> > > >>>>>> On Jun 10, 2013, at 2:12 PM, Mike Tutkowski < > > >>>> mike.tutkow...@solidfire.com> > > >>>>>> wrote: > > >>>>>> > > >>>>>>> Perhaps Wei could send me some screen shots of what he's changed > in > > >>>> the > > >>>>>> GUI > > >>>>>>> for his feature? > > >>>>>>> > > >>>>>>> Thanks! > > >>>>>>> > > >>>>>>> > > >>>>>>> On Mon, Jun 10, 2013 at 11:56 AM, John Burwell < > jburw...@basho.com > > > > > >>>>>> wrote: > > >>>>>>> > > >>>>>>>> Wei, > > >>>>>>>> > > >>>>>>>> Have Mike Tutkowski and you reconciled the potential conflict > > >>>> between a > > >>>>>>>> throttled I/O VM and a provisioned IOPs volume? If so, what > > >> solution > > >>>>>> did > > >>>>>>>> you select? > > >>>>>>>> > > >>>>>>>> Thanks, > > >>>>>>>> -John > > >>>>>>>> > > >>>>>>>> On Jun 10, 2013, at 1:54 PM, Wei ZHOU <ustcweiz...@gmail.com> > > >> wrote: > > >>>>>>>> > > >>>>>>>>> Guys, > > >>>>>>>>> > > >>>>>>>>> I would like to merge disk_io_throttling branch into master. > > >>>>>>>>> Please review the code on https://reviews.apache.org/r/11782 > > >>>>>>>>> > > >>>>>>>>> If nobody object, I will merge into master in 72 hours. > > >>>>>>>>> > > >>>>>>>>> -Wei > > >>>>>>>>> > > >>>>>>>>> 2013/5/30 Wei ZHOU <ustcweiz...@gmail.com> > > >>>>>>>>> > > >>>>>>>>>> Hi, > > >>>>>>>>>> I would like to merge disk_io_throttling branch into master. > > >>>>>>>>>> If nobody object, I will merge into master in 48 hours. > > >>>>>>>>>> The purpose is : > > >>>>>>>>>> > > >>>>>>>>>> Virtual machines are running on the same storage device (local > > >>>> storage > > >>>>>>>> or > > >>>>>>>>>> share strage). Because of the rate limitation of device (such > as > > >>>>>> iops), > > >>>>>>>> if > > >>>>>>>>>> one VM has large disk operation, it may affect the disk > > >>>> performance of > > >>>>>>>>>> other VMs running on the same storage device. > > >>>>>>>>>> It is neccesary to set the maximum rate and limit the disk I/O > > of > > >>>> VMs. > > >>>>>>>>>> > > >>>>>>>>>> The feature includes: > > >>>>>>>>>> > > >>>>>>>>>> (1) set the maximum rate of VMs (in disk_offering, and global > > >>>>>>>>>> configuration) > > >>>>>>>>>> (2) change the maximum rate of VMs > > >>>>>>>>>> (3) limit the disk rate (total bps and iops) > > >>>>>>>>>> JIRA ticket: > > >> https://issues.apache.org/jira/browse/CLOUDSTACK-1192 > > >>>>>>>>>> FS (I will update later) : > > >>>>>>>>>> > > >>>>>>>> > > >>>>>> > > >>>> > > >> > > > https://cwiki.apache.org/confluence/display/CLOUDSTACK/VM+Disk+IO+Throttling > > >>>>>>>>>> Merge check list :- > > >>>>>>>>>> > > >>>>>>>>>> * Did you check the branch's RAT execution success? > > >>>>>>>>>> Yes > > >>>>>>>>>> > > >>>>>>>>>> * Are there new dependencies introduced? > > >>>>>>>>>> No > > >>>>>>>>>> > > >>>>>>>>>> * What automated testing (unit and integration) is included in > > >> the > > >>>> new > > >>>>>>>>>> feature? > > >>>>>>>>>> Unit tests are added. > > >>>>>>>>>> > > >>>>>>>>>> * What testing has been done to check for potential > regressions? > > >>>>>>>>>> (1) set the bytes rate and IOPS rate on CloudStack UI. > > >>>>>>>>>> (2) VM operations, including > > >>>>>>>>>> deploy, stop, start, reboot, destroy, expunge. migrate, > restore > > >>>>>>>>>> (3) Volume operations, including > > >>>>>>>>>> Attach, Detach > > >>>>>>>>>> > > >>>>>>>>>> To review the code, you can try > > >>>>>>>>>> git diff c30057635d04a2396f84c588127d7ebe42e503a7 > > >>>>>>>>>> f2e5591b710d04cc86815044f5823e73a4a58944 > > >>>>>>>>>> > > >>>>>>>>>> Best regards, > > >>>>>>>>>> Wei > > >>>>>>>>>> > > >>>>>>>>>> [1] > > >>>>>>>>>> > > >>>>>>>> > > >>>>>> > > >>>> > > >> > > > https://cwiki.apache.org/confluence/display/CLOUDSTACK/VM+Disk+IO+Throttling > > >>>>>>>>>> [2] refs/heads/disk_io_throttling > > >>>>>>>>>> [3] https://issues.apache.org/jira/browse/CLOUDSTACK-1301< > > >>>>>>>> https://issues.apache.org/jira/browse/CLOUDSTACK-2071 > > >>>>> (CLOUDSTACK-1301 > > >>>>>> - > > >>>>>>>> VM Disk I/O Throttling) > > >>>>>>>>>> > > >>>>>>>> > > >>>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> -- > > >>>>>>> *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> > > >> *™* > > >> > > > > > > > -- > *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> > *™* >
