Mike don't feel bad it's my fault I think everyone knew you were working on the plugin actively and I assumed the proposal was already in place.
Can you call out your dependencies on Edison's framework? John I added as you as reviewers for Mike's contribution, can you pass on your comments. Thanks Animesh On May 30, 2013, at 9:09 PM, "Mike Tutkowski" <mike.tutkow...@solidfire.com> wrote: > Hi everyone, > > I apologize for being unfamiliar with how I should have gone about getting > consensus for the storage plug-in I developed for 4.2. > > I talked with Animesh and he has asked me to send out this proposal related > to the storage plug-in I built for 4.2 and submitted to Review Board > earlier this week. > > Here is a link to the design document: > > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Implement+SolidFire+(storage)+plug-in+and+expose+control+of+IOPS+to+admins+and+end+users > > Here is a link to the JIRA ticket: > > https://issues.apache.org/jira/browse/CLOUDSTACK-2778 > > Here is a link to it on Review Board: > > https://reviews.apache.org/r/11479/ > > Here is a high-level summary: > > I have developed a storage plug-in which makes use of the new storage > framework that Edison put in place for the 4.2 release. > > Working with Edison, I have identified a few areas of the storage framework > that needed to be enhanced (and I have done so in the code that I > submitted) for dynamic, zone-wide primary storage to function. > > This storage plug-in is specific to SolidFire (a data-storage company), > whose architecture is designed around Quality of Service. Each volume on > this SAN is assigned a Min, Max, and Burst number of IOPS. The Min is, as > one might expect, a guaranteed number (even in fault conditions) (as long > as the IOPS of the SAN are not over-provisioned). > > Per a discussion several months ago on this list, I have added into the > Disk Offerings Min, Max, and Burst values (all optional). These values > follow the patterns of the Disk Size field in that they can be customized > by the end user (in the Add Volume) if the admin decides to allow this. > > In the end, this feature allows users to create a 1:1 mapping between a > volume on the SAN and a data disk that can be attached to a VM (XenServer > supported...perhaps VMware, depending on time). This allows CloudStack > admins to offer their end users guaranteed IOPS on data disks (eliminating > the Noisy Neighbor effect). The plan is to support root disks in a post-4.2 > release. > > Again, I am sorry about my confusion regarding process here. I certainly > appreciate all of the input I have received on the e-mail list over the > past couple months while I was developing this feature. > > Please let me know if you have any questions. > > 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> > *™*
