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