[
https://issues.apache.org/jira/browse/CLOUDSTACK-2778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13731087#comment-13731087
]
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: https://issues.apache.org/jira/browse/CLOUDSTACK-2778
> 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:
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Implement+SolidFire+(storage)+plug-in+and+expose+control+of+IOPS+to+admins+and+end+users
> 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 plug-in.
> * 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: http://www.atlassian.com/software/jira
