Open Stack

On Nov 5, 2012, at 12:41 PM, Mark McLoughlin <markmc at redhat.com> wrote:

> On Mon, 2012-11-05 at 12:29 -0800, John Dickinson wrote:
>> I agree completely. The decision in my mind is around an official,
>> non-diluted OpenStack API that we as the community control and direct.
> 
> Care to elaborate on this "non-diluted/control" issue? It's additional
> to the "support and maintenance" issue?

It's absolutely additional.

It's vital that our community is able to control its own API. We can't depend on fast-following another API that is built against a closed implementation. Again, from the Swift project, we can't support the S3 API as a first-class member because the S3 API is fairly leaky about it's implementation. Our design decisions for Swift may mean that we are not able to support similar features with the same API. We may have a better API or just a different one based on the characteristics of Swift over S3's storage engine.

Which raises another point. S3 is not equivalent to Swift (just as Nova != EC2 or GCE). S3 can be compared to Rackspace Cloud Files, HP's Object Storage, Dreamhost's DreamObjects, and other object storage products. Those are all products. Swift is a storage engine that you can build a product on. For example, in the S3 API you have access to billing, identity, and regions. Each of those are concepts based on the product, not the storage engine. Specifically, Swift can be used to support a deployment with exactly the same regionality that S3 has--it's "just" a matter of a company building the appropriate DCs with the proper interconnected networking. But those deployment details are beyond the scope of Swift. Swift absolutely supports it (and we are working on making those specific features even better), but tying them together is well beyond the core storage system.

As to the scope of the discussion, the TC is figuring out the overall goals, resolving disputes, and managing integration. Features and implementations are up to the respective projects.

We must not allow our projects to be defined by products and implementations that we do not control. The best we can hope for in that case is to fast-follow and play catch up. We should be driving the technical conversation, not just the marketing conversation. The goal is to make world-class cloud infrastructure software that is open at all levels (the four opens), not to make a version of somebody else's successful product.

--John



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4329 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-tc/attachments/20121105/feb5180f/attachment-0001.bin>