[ https://issues.apache.org/jira/browse/CLOUDSTACK-2778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Sudha Ponnaganti updated CLOUDSTACK-2778: ----------------------------------------- Fix Version/s: 4.2.0 > 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