+1 on both of these. On Mon, Jan 30, 2012 at 10:52, Yehuda Sadeh Weinraub <yehuda@xxxxxxxxxxxxxxx> wrote: > 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 -- 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
