Bug Reference

https://issues.apache.org/jira/browse/CLOUDSTACK-2778

Branch

This code was being developing in my local solidfire_plugin branch. I recently built a patch file and submitted it for review.

https://reviews.apache.org/r/11479

Introduction

Purpose

This design document outlines the reason for this feature and the main sub-systems impacted.

References

Document History

Feature Specifications

  • SolidFire storage plug-in designed to support a 1:1 mapping between a SAN volume and a data disk. Control of IOPS is added into the Add Disk Offering and Add Volume dialogs. The plug-in storage framework is enhanced to support dynamic, zone-wide storage with XenServer (and with VMware, if time permits).
  • This storage plug-in is zone wide and intended to support at least XenServer, but also VMware (if time permits).
  • If it is easy enough to support KVM for this release, I would like to do so.
  • explain configuration characteristics:
    • A new bean has been added to the client/tomcatconf/applicationContext.xml.in file (look for the text "SolidFire").
  • deployment requirements (fresh install vs. upgrade): None
  • system requirements: memory, CPU, desk space, etc.: Nothing new
  • interoperability and compatibility requirements:
    • Supports XenServer and, if time permits, VMware
  • list localization and internationalization specifications: Nothing new
  • explain the impact and possible upgrade/migration solution introduced by the feature: None
  • explain performance & scalability implications when feature is used from small scale to large scale: Same as with current Disk Offerings/New Volumes
  • explain marketing specifications: This feature is being marketed actively by SolidFire and should increase interest in CloudStack.
  • explain levels or types of users communities of this feature (e.g. admin, user, etc): Impacts admins and users (only impacts users if admins allow this).

Use cases

General description of feature:

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.

Architecture and Design description

  • regarding database: talk about tables being added/modified
    • Main DB changes:
    • ALTER TABLE `cloud`.`disk_offering` ADD COLUMN `customized_iops` tinyint(1) unsigned NOT NULL DEFAULT 0 COMMENT 'Should customized IOPS be displayed to the end user';
    • ALTER TABLE `cloud`.`disk_offering` ADD COLUMN `min_iops` bigint(20) unsigned NOT NULL DEFAULT 0 COMMENT 'Minimum IOPS';
    • ALTER TABLE `cloud`.`disk_offering` ADD COLUMN `max_iops` bigint(20) unsigned NOT NULL DEFAULT 0 COMMENT 'Maximum IOPS';
    • ALTER TABLE `cloud`.`disk_offering` ADD COLUMN `burst_iops` bigint(20) unsigned NOT NULL DEFAULT 0 COMMENT 'Burst IOPS';
    • ALTER TABLE `cloud`.`volumes` ADD COLUMN `min_iops` bigint(20) unsigned NOT NULL DEFAULT 0 COMMENT 'Minimum IOPS';
    • ALTER TABLE `cloud`.`volumes` ADD COLUMN `max_iops` bigint(20) unsigned NOT NULL DEFAULT 0 COMMENT 'Maximum IOPS';
    • ALTER TABLE `cloud`.`volumes` ADD COLUMN `burst_iops` bigint(20) unsigned NOT NULL DEFAULT 0 COMMENT 'Burst IOPS';

Web Services APIs

Disk Offering creation has been extended to include optional parameters: Min, Max, and Burst IOPS as well as if these values should be user customizable.

Volume creation has been extended to include optional parameters: Min, Max, and Burst IOPS.

A storage plug-in has been implemented to create and delete volumes on a SAN dynamically (as is made possible via the storage plug-in framework).

The disk_offering table has four new fields: min_iops, max_iops, burst_iops, and a boolean to say whether these fields are user customizable.

The volumes table has three new fields: min_iops, max_iops, and burst_iops.

UI flow

  • Go to the Disk Offerings and elect to Add Disk Offering. Four new fields are present: User customizable, Min, Max, and Burst IOPS (all optional).
  • Go to the Storage tab and elect to Add New Volume. Three new fields are present (Min, Max, and Burst IOPS) if the admin wants to expose these to the end user.

IP Clearance

  • what dependencies will you be adding to the project? None
  • are you expecting to include any code developed outside the Apache CloudStack project? No

Appendix

Appendix A:

Appendix B:

  • No labels