cloudstack-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike Tutkowski (JIRA)" <>
Subject [jira] [Commented] (CLOUDSTACK-2778) Implement SolidFire (storage) plug-in and expose control of IOPS to admins and end users
Date Tue, 06 Aug 2013 18:49:47 GMT


Mike Tutkowski commented on CLOUDSTACK-2778:

Sorry...I was out of the office for a bit and didn't see these JIRA comments.

This ticket is now marked as closed.

I have been testing it over the past month or so and all seems to be working properly.

I am in the process of documenting the feature.
> Implement SolidFire (storage) plug-in and expose control of IOPS to admins and end users
> ----------------------------------------------------------------------------------------
>                 Key: CLOUDSTACK-2778
>                 URL:
>             Project: CloudStack
>          Issue Type: New Feature
>      Security Level: Public(Anyone can view this level - this is the default.) 
>          Components: API, Management Server, UI
>    Affects Versions: 4.2.0
>         Environment: All supported CloudStack environments
>            Reporter: Mike Tutkowski
>            Assignee: Mike Tutkowski
>             Fix For: 4.2.0
> Design Document:
> Implement a storage plug-in for SolidFire. The plug-in is based on the new storage framework
that went in with 4.2, as well.
> In addition, there are GUI (and related) changes to enable admins and end users to specify
a Min, Max, and Burst number of IOPS for a Disk Offering. These fields (although optional)
tend to follow the pattern previously established for the Disk Size field.
> Also, the storage framework itself needs to be enhanced. For example, it needs to support
creating and deleting storage repositories as is necessary for a dynamic type of zone-wide
primary storage (such as the SolidFire plug-in is).
> The desired behavior of the software is as such:
> * Allow an admin to invoke the CloudStack API to add Primary Storage based on the SolidFire
> * Allow an admin to create a Disk Offering that specifies a Min, Max, and Burst number
of IOPS or allows the admin to pass this ability on to the end user.
> * Allow an end user to execute such a Disk Offering. As is the case for any Disk Offering,
this leads to the creation of a row in the volumes table.
> * Allow an end user to attach the resultant volume (noted in the DB) to a VM. The storage
framework invokes logic in the plug-in and the plug-in creates a volume on its SAN with the
correct size and IOPS values. The agent software for XenServer detects that such an attach
is being requested and creates a Storage Repository (and single VDI within the SR) based on
the storage IP address of the SAN and the IQN of the volume. The VDI is then hooked up to
the VM.
> * Allow an end user to detach the volume. This leads to the destruction of the SR, but
the SAN volume remains intact and can be reattached later to any VM running in a XenServer
resource pool in the zone.
> * Allow an end user to delete the volume. This leads to the volume being deleted on the
SAN and being marked in the CloudStack DB as deleted.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:

View raw message