From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jason Dillaman Subject: Re: blueprint: consistency groups Date: Tue, 26 Apr 2016 11:09:01 -0500 Message-ID: References: <20160325071933.GA14634@gmail.com> Reply-To: dillaman@redhat.com Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Return-path: Received: from mail-qg0-f48.google.com ([209.85.192.48]:35257 "EHLO mail-qg0-f48.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751772AbcDZQJD (ORCPT ); Tue, 26 Apr 2016 12:09:03 -0400 Received: by mail-qg0-f48.google.com with SMTP id f74so6903902qge.2 for ; Tue, 26 Apr 2016 09:09:02 -0700 (PDT) In-Reply-To: Sender: ceph-devel-owner@vger.kernel.org List-ID: To: Victor Denisov Cc: Gregory Farnum , Mykola Golub , ceph-devel , Josh Durgin > The problem that I see with this approach is: let's say we start > adding an image to a cg and the cg is in adding image state. > It either means that somebody is already adding an image to this cg or > somebody died while adding this image. > And we can't really understand it. The metadata link from CG -> image should be in the "adding" state, not the entire CG. There shouldn't be anything preventing concurrently adding two different images to a CG. > > So, my suggestion is: normally the command fails if it finds the cg in > an unexpected state. > If the user adds flag --force then it picks up this unfinished > operation and completes it and then adds the new image. > How does that sound? My concern w/ adding a "--force" command for this is that it can be abused. Personally, I'd rather see that the API is robust enough to handle these partial states. If an "add" fails, I should be able to repeat the "add" and have it work or run "remove" to have it clean up any intermediate state. -- Jason