[openstack-dev] [Cinder][Manila]

Swartzlander, Ben Ben.Swartzlander at netapp.com
Sun Apr 27 02:00:16 UTC 2014


> -----Original Message-----
> From: Alun Champion [mailto:prof at achampion.net] 
> Sent: Saturday, April 26, 2014 7:19 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: [openstack-dev] [Cinder][Manila]
>
> I'm sure this has been discussed I just couldn't find any reference to it, perhaps someone can point me to the discussion/rationale.
> Is there any reason why there needs to be another service to present a control-plane to storage? Obviously object storage is
> different as that is presenting a data-plane API but from a control-plane I'm confused why there needs to be another service,
> surely control-planes are pretty similar and the underlying networking issues for iSCSI would be similar for NFS/CIFS.
> Trove is looking to be a general purpose data container
> (control-plane) service for traditional RDBMS, NoSQL, KeyValue, etc., why is the Cinder API not suitable for providing a general
> purpose storage container (control-plane) service?
>
> Creating separate services will complicate other services, e.g. Trove.
>
> Thoughts?

There are good arguments on both sides of this question. There is substantial overlap between Cinder and Manila in their API constructs and backends (they both deal with storage, after all). In the long run it's entirely possible that the 2 projects could be merged.

However there are also some very important differences. In particular Cinder knows almost nothing about networking, but Manila needs to know a great deal about individual tenant networks in order to deliver NAS storage to tenants. Cinder can rely on hypervisors to do some of the hard work of translating block protocols and managing attaching/detaching whereas Manila routes around the hypervisor entirely and connects guest VMs with storage directly. The most important reason Manila ended up as a separate project from Cinder was because the Cinder team didn't want the distraction of dealing with some of the very hard technical problems that needed solving for Manila to be successful.

After working on Manila for the past year and struggling with a lot of hard technical decisions I think it was the right decision to split the projects. If Manila had remained a subproject of Cinder then it either wouldn't have received near the attention it needed or it would have sucked attention away from a lot of important issues that the Cinder team is dealing with.

If there's a future where Manila and Cinder merge back together then I'm pretty sure it's quite far away. The best thing we can do is strive to make both projects successful and keep asking these hard questions.

-Ben Swartzlander (Manila PTL)




More information about the OpenStack-dev mailing list