[jira] [Comment Edited] (CLOUDSTACK-2778) Implement SolidFire (storage) plug-in and expose control of IOPS to admins and end users

["Sudha Ponnaganti (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CLOUDSTACK-2778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13696086#comment-13696086 ] 

Sudha Ponnaganti edited comment on CLOUDSTACK-2778 at 6/29/13 10:50 AM:
------------------------------------------------------------------------


Waned to check on QAaspect for this feature. 
- See ticket description/ design document for feature description
- Can someone pick this up from community to do functional QA /Automation for this plug-in.
- Pl see cwiki for test plans and execution results templates 

                
      was (Author: sudhap):
    
Waned to check on QAaspect for this feature. 
- See ticket description.FS for feature description
- Can someone pick this up from community to do functional QA /Automation for this plug-in.
- Pl see cwiki for test plans and execution results templates 

                  
> 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