EMC ECS driver

Registered by Parashuram Hallur

This blueprint is being submitted for the EMC ECS (Elastic Cloud Storage) hyper scale storage infrastructure system. ECS is an appliance that provides block, object, and HDFS capabilities natively and combines commodity infrastructure with resilient data services. The EMC ECS appliance will support block volume services through the initial Cinder driver contribution. EMC ECS supports EMC HW and certified commodity HW.

The ECS appliance leverages EMC ViPR as its element manager and, therefore, the code being submitted for the ECS Cinder driver is identical to the code submitted formerly for the EMC ViPR iSCSI and FC Volume Driver Blueprint . Our intent with this blueprint/cinder driver is to request approval for the ECS appliance, however we want to clarify that approval of this Cinder driver will also allow EMC ViPR to support OpenStack as well for managing EMC storage systems (VMAX, VNX and VPLEX).

The specific appliance/volumes serviced by the proposed Cinder Driver

1) Cinder Block Volume Driver for EMC ECS
2) Cinder iSCSI and FC Block Volume Driver for EMC ViPR to manage EMC storage systems – VMAX, VNX and VPLEX

Also, please note that EMC VMAX and VNX will continue to have native Cinder driver in addition EMC ViPR driver to support OpenStack.

The proposed ECS and EMC ViPR Cinder driver will support the necessary minimum API sets for the target release.

You can find additional details regarding EMC ECS and ViPR in the following links:
Pulse Blog Regarding EMC ECS:
http://pulseblog.emc.com/2014/05/05/new-emc-ecs-appliance-vipr-2-0-redefine-whats-possible-storage-management-globally-distributed-customers/

EMC ECS Press Release:
(http://www.emc.com/about/news/press/2014/20140505-02.htm)

EMC ECS Data Sheet:
http://www.emc.com/collateral/specification-sheet/h13117-emc-ecs-appliance-powered-by-vipr-ss.pdf

Blueprint information

Status:
Complete
Approver:
John Griffith
Priority:
Low
Drafter:
Parashuram Hallur
Direction:
Needs approval
Assignee:
Parashuram Hallur
Definition:
Obsolete
Series goal:
None
Implementation:
Good progress
Milestone target:
None
Started by
Parashuram Hallur
Completed by
Sean McGinnis

Related branches

Sprints

Whiteboard

We are mostly code complete and testing the driver in-house is in progress

<jdg, 2/6/14>
Understanding this is still pending legal review but that the code is ready. I'm holding off on removing from Icehouse but after FFE I don't think we'll make an exception here.

2/10/2014 XY
ViPR driver is approved by EMC legal to contribute to Icehouse.

Gerrit topic: https://review.openstack.org/#q,topic:bp/emc-vipr-iscsi-and-fc-volume-driver,n,z

Addressed by: https://review.openstack.org/74158
    EMC ViPR iSCSI and FC volume drivers

<jdg, 2/17/14>
So there's an interesting trend lately for vendors to put their storage virtualization pieces under Cinder and basicly duplicate what Cinder tries to accomplish but to fit their own model. I'm not crazy about this and it seems like the complete wrong direction. When I first discussed this with EMC there was talk of this replacing all of the other EMC drivers in the tree, which would be one thing. But doing an incremental add of an entire service like this inside of Cinder disguised as a driver seems like the complete wrong way to go.

If there are really that many things that Cinder doesn't provide well enough, this doesn't solve it because you're still using the Cinder API, if there are additional things being exposed that are useful then why not enhance or help to make Cinder better and address the missing aspects that you want to see added in the core project?

I'm going to continue to hold my stance on the idea that virtual storage services on top of virtual storage services is not the right way to go for Cinder. If you want to contribute and rewrite Cinder that's great but this is certainly a slippery slope and not a good one. If this is truly a better way to go and a needed feature/driver in Cinder I think it's fine to offer it on your own github outside of tree but I don't think it belongs in Cinder. It sends confusing messages and completely fractures the service.

<rwe, 5/24/14>
We completely agree w/ JDG. It's hard to argue this would be additive to the community given what seems a pretty naked attempt to subvert the whole Cinder model.

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

Addressed by: https://review.openstack.org/104639
    EMC ECS ( Elastic Cloud Storage ) Driver for Juno

<Parashuram Hallur, 10/30/2014>
We are planning to resubmit the driver for Kilo

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.