I'm not sure how that would work if the user picks SolidFire, but then specifies a Storage Tag that doesn't include SolidFire.
As far as I know, Min, Max, and Burst is a superset for current storage vendors that do provisioned IOPS of some sort. On Mon, Jun 10, 2013 at 1: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> *™*
