On Mon, Sep 29, 2014 at 4:15 PM, Clint Byrum <cl...@fewbar.com> wrote:

> It would, however, be bad to get a 404 for something that is otherwise
> present.. as that will result in an erroneous failure for the client.
That almost never happens, but is possible if all the primaries are down*,
a system than leans harder on the C a similar failure would be expected to
treat a similar impossible question as a failure/error.

* It's actually if all the same nodes that answered the previous write are
down; there's some trixies with error-limiting and stable handoffs that
help with subsequent read-your-writes behavior that actually make it fairly
difficult to write data that you can't then read back out unless you
basically track where all of the writes go and then shut down *exactly*
those nodes and make a read before replication beats you to it.  Just
shutting down all three primary locations will just write and then read
from the same handoff locations, even if the primaries subsequently come
back online (unless the primaries have an old copy - but it sounds like
that's not going on in your application).

Again, all of this has to do with under failure edge cases.  A healthy
swift system; or even one that's only moderately degraded won't really see
much of this.

Depending on the deployment latencies may be a concern if you're using this
as a "cache" - have you looked at Swauth [1] already?


1. https://github.com/gholt/swauth
OpenStack-dev mailing list

Reply via email to