We are essentially working on both. :) For 4.2, I intend on having a SolidFire plug-in available.
But, in the meanwhile, we don't want to not have a solution available for customers today and those tomorrow who aren't going to be on 4.2 right away. We want to say we have *some* solution for them...even if it's not ideal right away. On Thu, Feb 7, 2013 at 3:43 PM, Ahmad Emneina <aemne...@gmail.com> wrote: > My $0.02 is $solidfiredev should focus on the end goal of implementing > this awesome feature, and not some interim solution that wont be supported > going forward. > > > On Thu, Feb 7, 2013 at 2:06 PM, Mike Tutkowski < > mike.tutkow...@solidfire.com> wrote: > >> So, yeah, at this point, I'm playing around with ideas. I'm thinking my >> initial flow, while not perfect by any means (reference potential race >> condition), might work sufficiently. >> >> I definitely would like to tap people in the CloudStack community for a >> sanity check, though. :) >> >> >> On Thu, Feb 7, 2013 at 2:30 PM, Mike Tutkowski < >> mike.tutkow...@solidfire.com> wrote: >> >>> Exactly...and Edison's new plug-in architecture will enable us to create >>> a volume per VM Instance or Data Disk, but that won't be out until 4.2. >>> >>> In the meanwhile, I'm kind of brainstorming to see if I can write a >>> script to enable this functionality before 4.2 (and for customers who won't >>> upgrade to 4.2 right away when it comes out). >>> >>> >>> On Thu, Feb 7, 2013 at 2:27 PM, Ahmad Emneina <aemne...@gmail.com>wrote: >>> >>>> got it. the iops are shared amongst guest vm disks that reside on a >>>> volume. So is the idea to create a volume per vm? >>>> >>>> >>>> On Thu, Feb 7, 2013 at 1:22 PM, Mike Tutkowski < >>>> mike.tutkow...@solidfire.com> wrote: >>>> >>>>> Also, when I say "volume", that is equal to "LUN" when talking about >>>>> SolidFire. >>>>> >>>>> >>>>> On Thu, Feb 7, 2013 at 2:21 PM, Mike Tutkowski < >>>>> mike.tutkow...@solidfire.com> wrote: >>>>> >>>>>> Hi Ahmad, >>>>>> >>>>>> Thanks for the comments. >>>>>> >>>>>> In regards to your first idea about creating multiple targets on the >>>>>> SolidFire system, I'd be concerned that I wouldn't know how many to >>>>>> create. >>>>>> Would I make 100...200...? Not sure. Since SolidFire can control IOPS >>>>>> on >>>>>> a per-volume basis, in our ideal world, each VM Instance or Data Disk >>>>>> would >>>>>> be serviced by a single SolidFire volume. If I ever have more than one >>>>>> VM >>>>>> Instance, for example, running on the same SolidFire volume, I can't >>>>>> guarantee any individual VM its IOPS (as its IOPS may be absorbed >>>>>> unequally >>>>>> by the other VM(s) running on the same volume). >>>>>> >>>>>> Does that make sense? If you see some flaw in my logic, please let >>>>>> me know. :) >>>>>> >>>>>> Thanks! >>>>>> >>>>>> >>>>>> On Thu, Feb 7, 2013 at 1:02 PM, Ahmad Emneina <aemne...@gmail.com>wrote: >>>>>> >>>>>>> Hey Mike, >>>>>>> >>>>>>> The cleanest approach as a user would be: >>>>>>> I create multiple targets on the solid fire. Each with a different >>>>>>> IOPs setting (assuming you can control max iops for volumes this way). >>>>>>> I'd >>>>>>> mount each to the hypervisor and create a specific service offering for >>>>>>> each. That way youre intercepting calls with a script and modifying >>>>>>> tags/offerings on the fly, and avoid said race condition. >>>>>>> >>>>>>> second cleanest approach IMO: >>>>>>> Or to backpack off your previous method. Create 3 different service >>>>>>> offerings (fast, medium, slow). That way when the deploy vm is called, >>>>>>> your volume create script can intercept the call and will know the QOS >>>>>>> based on the offering. >>>>>>> >>>>>>> Why I'd do this is say you change the service offering to fast while >>>>>>> provisioning a vm, and a user with a disk thats meant to be slow reboots >>>>>>> her vm... she'll be upgraded to fast. All because your modifying the one >>>>>>> and only offering. >>>>>>> >>>>>>> >>>>>>> On Thu, Feb 7, 2013 at 11:17 AM, Mike Tutkowski < >>>>>>> mike.tutkow...@solidfire.com> wrote: >>>>>>> >>>>>>>> Hi everyone, >>>>>>>> >>>>>>>> I learned yesterday that Edison's new storage plug-in architecture >>>>>>>> will >>>>>>>> first be released with 4.2. >>>>>>>> >>>>>>>> As such, I began to wonder if there was any way outside of >>>>>>>> CloudStack that >>>>>>>> I could support CloudStack users who want to make use of >>>>>>>> SolidFire's QoS >>>>>>>> feature (controlling IOPS). >>>>>>>> >>>>>>>> A couple of us brainstormed for a bit and this is what we came up >>>>>>>> with. >>>>>>>> Can anyone confirm if this could work? >>>>>>>> >>>>>>>> ******************** >>>>>>>> >>>>>>>> The CloudStack Admin creates a Primary Storage that is of the type >>>>>>>> PreSetup. This is tagged with a name like "SolidFire_High" (for >>>>>>>> SolidFire >>>>>>>> High IOPS). >>>>>>>> >>>>>>>> The CloudStack Admin creates a Compute Offering that refers to the >>>>>>>> "SolidFire_High" Storage Tag. >>>>>>>> >>>>>>>> In the CSP's own GUI, a user picks the Compute Offering referred to >>>>>>>> above. >>>>>>>> The CSP's code sees the Storage Tag "SolidFire_High" and that cues >>>>>>>> it to >>>>>>>> invoke a script of mine. >>>>>>>> >>>>>>>> My script is passed in the necessary information. It creates a >>>>>>>> SolidFire >>>>>>>> volume with the necessary attributes and hooks it up to the >>>>>>>> hypervisor >>>>>>>> running in the Cluster. It updates my Primary Storage's Tag with >>>>>>>> the IQN >>>>>>>> (or some unique identifier), then it updates my Compute Offering's >>>>>>>> Storage >>>>>>>> Tag with this same value. >>>>>>>> >>>>>>>> Once the Primary Storage and the Compute Offering have been updated, >>>>>>>> CloudStack can begin the process of creating a VM Instance. >>>>>>>> >>>>>>>> Once the VM Instance is up and running, the CSP's GUI could set the >>>>>>>> Primary >>>>>>>> Storage's and Compute Offering's Storage Tags back to the >>>>>>>> "SolidFire_High" >>>>>>>> value. >>>>>>>> >>>>>>>> ******************** >>>>>>>> >>>>>>>> The one problem I see with this is that you would have to be sure >>>>>>>> not to >>>>>>>> kick off the process of creating such a Compute Offering until your >>>>>>>> previous such Compute Offering was finished (because there is a race >>>>>>>> condition while the Storage Tag field points to the IQN (or some >>>>>>>> other >>>>>>>> unique identifier)). >>>>>>>> >>>>>>>> Thanks! >>>>>>>> >>>>>>>> -- >>>>>>>> *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> >> *™* >> > > -- *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> *™*
