Open Stack

I strongly disagree.

Would we be happy if we stripped out all of the code out of nova for non kvm and said, "if you want vmware or xen, support you have to reimplement nova from scratch in an api compatible way out of tree"? "And on top of that, we won't ever test compatibility for anything not nova-kvm, its not openstack"?

What about cinder? "We only support iscsi, if you want a cinder api that speaks to ceph, you need to reimplement all the cinder api yourself out of tree, and we won't support any tests"?

Trove, you can deploy any db you want so long as its mysql... sahara, anything so long as its vanilla hadoop.... etc.

Of course not. Why is Swift special here? There's a reason those other openstack projects provide flavors. Because no single backend has proven to work for 100% of the users use cases.

The same need has shown up for Swift. The protocol is great. The implementation, while also great for a lot of folks/use cases (truely.), it doesn't work for all use cases an op has. An op has to make an exclusive choice today, and its hard on ops and other vendors. Why is this situation acceptable for Swift and not other openstack projects?

As an Op, I have personally seen 2 impediments:
1. We currently run the radosgw. Other vendors support stuff like swift api backed to tape. we are interested in it but cant since there can be only one thing and the radosgw case is currently more important. This leaves us to choose between the least bad of the partial solutions, not a complete one.

2. Incompatibilities in api. This has shown up, for example, in Trove not being able to backup to a radosgw.

I believe most the reason for this is lack of testing, and thats been hung up on:
 1. circular logic around, the swift software defines the swift api. We don't have to standardize it since its in tree and nothing else can be swift.
 2. we don't have to support tests for anything but "swift". since the swift software is the api reference by definition above, there is little point in testing much other then, is swift enabled or not. If its not the swift software, it couldn't possibly be the swift api and we shouldn't test compatibility. I think this is a horrible thing.
 
Operators have indeed seen issues with it. Saying its been "successful" is incorrect. Its been mostly good enough sort of with a bunch of issues that have plagued us.

Thanks,
Kevin
________________________________________
From: Pete Zaitcev [zaitcev at redhat.com]
Sent: Thursday, May 05, 2016 9:38 AM
To: Fox, Kevin M
Cc: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [tc] Swift api compat. Was: supporting Go

On Wed, 4 May 2016 21:52:49 +0000
"Fox, Kevin M" <Kevin.Fox at pnnl.gov> wrote:

> Swift is in a strange place where the api is implemented in a way to
> favor one particular vendor backend implementation.

Sorry, but I disagree with the above assessement. There is no one
particular vendor like that, because the only vendor of Swift source
is OpenStack, and vendors of pre-packaged Swift are legion, all equal:
Red Hat, HPe (Helion), SwiftStack, Mirantis, and more.

> I'd love to be able to plugin Swift into our sites, but because we
> can only have one, the various tradoffs have lead us to deploy RadosGW
> most of the time.

The fact that you succeeded in running OpenStack with RadosGW proves that
there is no issue here that impedes a development or use of OpenStack.
We at Red Hat will be happy to support an installation of OpenStack using
Ceph underpinning it as integrated storage solution. Or, an installation
that uses the OpenStack-released, reference implementation of Swift,
which we integrate too. We're flexible like that, according to the needs
of each customer.

-- Pete