Cinder

Add Federator Volume Driver to Support ProphetStor Federator Storage in Cinder

Registered by Steven Tan

Overview
=======
ProphetStor Federator is a software-defined storage platform that supports multiple storage back-ends to enhance Cinder functionalities. Federator abstracts, pools, and automatically provisions the appropriate type of storage based on the selected Cinder volume-type.

Implementation
===========
Federator provides storage discovery, pooling, classification, offering and provisioning functions.

Federator supports discovery of storage arrays through SMI-S and CDMI standards, and native storage protocols. Discovered storage resources are imported, along with their associated storage characteristics, and abstracted into virtual storage pools that can be classified based on their capabilities, and performance characteristics. Administrators can set arbitrary cost value for virtual storage pools to provide differentiated storage tiers.

Administrators create Storage Offerings that are exposed as volume-type(s) in Cinder; capabilities and performance details for the Storage Offerings appear in the extra-specs of each volume-type.

Users create volumes through Cinder CLI or Horizon Dashboard by selecting a volume-type, and Federator dynamically selects a virtual storage pool that matches the Storage Offering requirements.

Features
======
The driver supports all required minimum features for IceHouse:
- Volume Create/Delete
- Volume Attach/Detach
- Snapshot Create/Delete
- Create Volume from Snapshot
- Get Volume Stats
- Copy Image to Volume
- Copy Volume to Image
- Clone Volume
- Extend Volume

In addition to the minimum feature set, Federator also provides:
- Volume Rollback

Blueprint information

Status:
Complete
Approver:
John Griffith
Priority:
Undefined
Drafter:
Steven Tan
Direction:
Needs approval
Assignee:
Rick Chen
Definition:
Obsolete
Series goal:
None
Implementation:
Needs Code Review
Milestone target:
None
Started by
Steven Tan
Completed by
Sean McGinnis

Related branches

Sprints

Whiteboard

(smcginnis): Marking obsolete as this has been sitting out there for a long time. If this is still needed, please submit a new bp.

<Steve> certification report submitted, please review and approve
http://download.prophetstor.com/cinder-cert-results/tmp.xxukm4wR5c

<Steve> prophetstor-federator-driver connects storage systems that Cinder DOES NOT SUPPORT (such as ProphetStor Flexvisor, FalconStor IPStor, Dell Compellent etc.) to Openstack. Similar to Solidfire, Nexenta, or other drivers, this driver does not interfere with Cinder in anyways, except uses it to plug our product into it. I agree with you about merging our features to cinder and we are very willing to do that for the next release.

We will run through the cert tests, please help get it into icehouse release. Thanks!

<thingee> We still need the cert tests ran for this to be reviewed/merged. https://wiki.openstack.org/wiki/Cinder/certified-drivers#Testing_for_current_Icehouse_release

John, work is completed. Please review and approve. Thanks, Steve

<jdg>If you still finish on time there's no reason you can't submit the patch, but given no updates/communication I'm deferring to I3

<jdg> Still zero progress displayed and no communication what soever. Considering bumping this again, FFE is just around the corner and new drivers are absolutely the lowest priority at this point. Please update your status.

Also, I've already removed your other BP (https://blueprints.launchpad.net/cinder/+spec/prophetstor-dpl-driver) from targeting. Seems a bit unrealistic to tackle both of these at this point given there's been no movement on either one.

Gerrit topic: https://review.openstack.org/#q,topic:bp/prophetstor-federator-driver,n,z

<jdg> This isn't actually implemented and there are two separte items, the DPL driver and the Storage as a Service code. The SaaS still raises concerns under the whole idea/concept that I think we need to discuss still. My personal opinion is that I've rejected any abstraction layers under the Cinder abstraction that duplicate everything Cinder is aiming to do and I'll probably continue to take that stance, however I'm more than willing to take input from the community and be *convinced* if it seems I'm going the wrong way. Philosophically however I think this is the wrong direction for Cinder and I'm perfectly happy to discuss and explain further via the ML or IRC.

Cinder cert results:http://download.prophetstor.com/cinder-cert-results/tmp.xxukm4wR5c

Addressed by: https://review.openstack.org/99616
    Add ProphetStor Federator Volume Driver for cinder

cinder cert result: http://download.prophetstor.com/cinder-cert-results/tmp.vOAdhQdDsy

How do you propose to provide Volume Rollback without a Cinder API for this function?
<Rick> The volume rollback function is proposed in separate blueprint https://blueprints.launchpad.net/cinder/+spec/cinder-volume-rollback-snapshot. It is ready for review and merge in IceHouse. I will porting it to Juno soon. The rollback function in Federator Volume Driver is isolated. Before the Cinder API implement the volume rollback, it won't be called.

<steve> we are still trying to get this in for juno-2 pending john's review on this topic. rollback is an optional feature as stated by Rick, the driver is ready to support it when Cinder implements the rollback blueprint.

You should not set a milestone target unless the blueprint has been properly prioritized by the project drivers.
(This is an automated message)

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.