cloudstack-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike Tutkowski (JIRA)" <>
Subject [jira] [Created] (CLOUDSTACK-2778) Implement SolidFire (storage) plug-in and expose control of IOPS to admins and end users
Date Fri, 31 May 2013 00:22:20 GMT
Mike Tutkowski created CLOUDSTACK-2778:

             Summary: Implement SolidFire (storage) plug-in and expose control of IOPS to
admins and end users
                 Key: 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

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