OpenStack Storage benefits/features misleading

[jnoller]

Brought to my attention by other storage engineers looking heavily at openstack. I was asked if I could assist in altering the page / raising this issue so it could be better, more clear and less misleading. Comments follow:

"""
The main issue is that a lot of the cited benefits are relative to some alternative, but it's not made clear what those alternatives are. While this is fine when promoting Swift vs. proprietary NAS, people are also using this list to promote Swift vs. things like GlusterFS or Ceph where those advantages are weak or non-existent (or even reversed). *Purely to illustrate the point*, I've taken the list from http://www.openstack.org/software/openstack-storage/ and replaced the "benefit" column with one identifying the relevance to other open-source storage solutions - not just filesystems like GlusterFS and Ceph but also things like Riak CS. I've put the result here:

http://pl.atyp.us/drafts/2013-11-swift-bs.html

As you can see, the "OK" entries (true advantages for Swift) are a small minority. Without context, a "no X" claim implies that it's commonplace for alternatives to require X. An "unlike X" claim implies that most alternatives have X. This is particularly egregious in the case of performance claims, which we both know are unsubstantiated by *any* serious comparison to *any* alternative (plus it's unlikely for any HTTP-based protocol to excel here). So, what would I do to improve it?

(1) Don't try to talk about block and object storage all at once. They're too different. Mixing items that only apply to block and items that only apply to object just makes things look weird.

(2) Scale back some of the no/higher/unlike claims, and eliminate some of the meaningless ones (e.g. "optimized for scale" or "elastic data scaling with ease").

(3) Present it as a matrix, with Swift in one column and other broad categories (e.g. scale-out and traditional NAS) in the others. Most cells - e.g. "leverages commodity hardware" - could be simple checks, exes, or question marks. A few, such as supported replication levels, could have other values.

This could still be done in a way that clearly favors Swift, without actually misrepresenting the competitive landscape. I'd even be willing to take a stab at it myself, but I think it would be more appropriate for somebody with more of an OpenStack perspective to make an attempt first.
"""

[Lauren Sell (lauren-openstack)]

Jesse, thanks for the detailed comments, this is really good feedback. We are planning to update the different software pages in advance of the Icehouse release. We have a content team who will be pitching in on the effort, and could definitely use some storage expertise. We always have calls with the different PTLs prior to updating the software pages, but it's also helpful to get input from users and those with a good view of the market/competitors. The next content meeting is scheduled for March 13 if you want to attend or pass this along to those who brought it to your attention. You can see the whole meeting schedule here: https://wiki.openstack.org/wiki/Governance/Foundation/Marketing, or register for the content meeting specifically here: http://openstack.enterthemeeting.com/m/MR2ZN9JR.