cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Animesh Chaturvedi <>
Subject Re: [PROPOSAL] Storage plug-in for 4.2
Date Fri, 31 May 2013 04:31:49 GMT
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. 


On May 30, 2013, at 9:09 PM, "Mike Tutkowski" <> 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:
> Here is a link to the JIRA ticket:
> Here is a link to it on Review Board:
> 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:
> o: 303.746.7302
> Advancing the way the world uses the
> cloud<>
> *™*

View raw message