> Perhaps there is still a bug where an image is getting stuck in 'saving' or > some other state when a PUT fails?
Yes, that's precisely the problem. Of course, one could argue that that if an upload fails the user should be able to continue trying until the upload succeeds! But in that case the image status should probably be reset to "queued" rather than stay at "saving". But this makes me a little uneasy because our consistency/concurrency handling seems a little weak at the moment (am I right?). If we were to have a more complicated state machine then we would need much stronger consistency guarantees when there are simultaneous uploads in progress (where some fail and some succeed)! Is there any work on this (concurrency/consistency) front? I remember seeing some patches related to caching of simultaneous downloads of an image file where issues related to concurrent update of image metadata were addressed but IIRC it was -1ed because it reduced concurrency. So do we bring back the 'killed' state or should we shoot for a more complicated/powerful state machine? -- Koo On Sun, Jan 26, 2014 at 06:36:36AM -0800, Mark Washenberger wrote: > It does not seem very ReSTful--or very usable, for that matter--for a > resource to be permanently modified when you a PUT fails. So I don't think > we need the 'killed' status. It was purposefully left out of v2 images, > which is not just a reskin of v1. > > Perhaps there is still a bug where an image is getting stuck in 'saving' or > some other state when a PUT fails? > > > On Sun, Jan 26, 2014 at 5:10 AM, David Koo <kpublicm...@gmail.com> wrote: > > > > > Hi Fei, > > > > Thanks for the confirmation. > > > > > I think you're right. The 'killed' status should be set in method > > upload() > > > if there is an upload failure, see > > > > > https://github.com/openstack/glance/blob/master/glance/common/utils.py#L244 > > > > I think you meant: > > > > > > https://github.com/openstack/glance/blob/master/glance/api/v1/upload_utils.py#L244 > > > > (the safe_kill() call) right? > > > > -- > > Koo > > > > > > > ------------------ Original ------------------ > > > From: "David Koo"<kpublicm...@gmail.com>; > > > Date: Jan 26, 2014 > > > To: "OpenStack Development Mailing > > > List"<openstack-dev@lists.openstack.org>; > > > Subject: [openstack-dev] [Glance] Is the 'killed' state ever set in v2? > > > > > > Hi All, > > > > > > While trying to work on a bug I was trying to simulate some image > > > download failures and found that apparently the 'killed' state is never > > > set using v2 APIs. > > > > > > If I understand correctly, a file upload goes to > > > api.v2.image_data.ImageDataController.upload and goes all the way to > > > store.ImageProxy.set_data which proceeds to write to the backend store. > > > > > > If the backend store raises an exception it is simply propagated all the > > > way up. The notifier re-encodes the exceptions (which is the bug I was > > > looking at) but doesn't do anything about the image status. > > > > > > Nowhere does the image status seem to get set to 'killed'. > > > > > > Before I log a bug I just wanted to confirm with everybody whether or > > > not I've missed out on something. > > > > > > Thanks. > > > > > > -- > > > Koo > > > > _______________________________________________ > > OpenStack-dev mailing list > > OpenStack-dev@lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev