On Mon, Jan 30, 2012 at 10:42 AM, Sage Weil <sage@xxxxxxxxxxxx> wrote: > > One of the failure we see in qa during osd thrashing is failure from > commands like 'ceph osd out 2'. A transient (say, network) error can > prevent the ceph command from getting the reply, and when it is resent we > get EINVAL 'already marked down' or similar. > > In general, should we make these commands return success in those cases? > Or should callers be prepared to tolerate those sorts of errors? I'd say that in any case where the end result is the expected state, then we should return success (e.g., avoid error when already marked down). Where there's real error we sholdn't hide it. > > The in/out/down ones seem pretty straightward to me. A tricker one is > 'ceph osd create 123', which currently fails if 123 already exists (and > you thus do not get to use that id). Not that we do that; the chef stuff > will do 'ceph osd create' and a newly allocated id will be part of the > reply. > We can let the client decide whether this is an error or not by adding 'exclusive' flag to the request (and make it the default behavior). Yehuda -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
