> -----Original Message-----
> From: Alun Champion [mailto:[email protected]] 
> 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)


_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to