cloudstack-dev mailing list archives

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

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.


*Mike Tutkowski*
*Senior CloudStack Developer, SolidFire Inc.*
o: 303.746.7302
Advancing the way the world uses the

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message