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