Hi Animesh, Sure, I'd be happy to do that.
Would you like these comments in this e-mail chain, the design doc, and/or the JIRA ticket? Also, just to make sure I understand correctly when we refer to "dependencies" here, the plug-in simply requires the storage-framework changes that Edison put in place for 4.2. As long as those are in place (along with the enhancements I made to his storage framework), then the plug-in will function. There are no additional libraries used by the plug-in that were not already in use within CloudStack. Thanks! On Thu, May 30, 2013 at 10:31 PM, Animesh Chaturvedi < animesh.chaturv...@citrix.com> wrote: > 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> > > *™* > -- *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> *™*
