Open Stack

> 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 <kpublicmail at 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"<kpublicmail at gmail.com>;
> > > Date:  Jan 26, 2014
> > > To:  "OpenStack Development Mailing
> > > List"<openstack-dev at 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 at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >

> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev