blob stuck in saving status
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Glare |
Fix Released
|
High
|
Kushal Agrawal |
Bug Description
blob stuck in "saving" status.
glare upload results with: INFO - ERROR (app) HTTPConflict (HTTP 409)
When going to glare_artifact_
When Trying to delete the artifact we get 409 (as expected):
{"explanation": "There was a conflict when trying to complete your request.", "code": 409, "error": {"message": "You cannot change artifact status if it has uploading blobs.", "type": "Conflict"}, "title": "Conflict"}
ERROR (app) HTTPConflict (HTTP 409)
Traceback (most recent call last):
File "/usr/lib/
result = cmd.run(
File "/usr/lib/
return super(Command, self).run(
File "/usr/lib/
return_code = self.take_
File "/usr/lib/
type_
File "/usr/lib/
self.
File "/usr/lib/
return self.request(url, "DELETE", **kwargs)
File "/usr/lib/
raise exc.from_
HTTPConflict: HTTPConflict (HTTP 409)
Traceback (most recent call last):
File "/usr/bin/glare", line 10, in <module>
sys.
File "/usr/lib/
return GlareShell(
File "/usr/lib/
result = self.run_
File "/usr/lib/
result = cmd.run(
File "/usr/lib/
return super(Command, self).run(
File "/usr/lib/
return_code = self.take_
File "/usr/lib/
type_
File "/usr/lib/
self.
File "/usr/lib/
return self.request(url, "DELETE", **kwargs)
File "/usr/lib/
raise exc.from_
glareclient.
Changed in glare: | |
assignee: | nobody → Kushal Agrawal (kushal2605) |
Usually the service automatically deletes a blob instance if there was an error during uploading process. For sure we can't guarantee this behavior always, because in some cases mysql db doesn't respond in time.
I agree that we must prevent such situations and allow users to delete blobs with 'saving' status.
But we must do it right and exclude the situations when malicious users will reupload their data, and therefore clog the storage.
My proposal is to add a new policy for deleting blobs with saving status and let only operators perform this action.