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