)]}'
{"/COMMIT_MSG":[{"author":{"_account_id":1179,"name":"Clay Gerrard","email":"clay.gerrard@gmail.com","username":"clay-gerrard"},"change_message_id":"d1f88bc702840625106006c1fab25e34bfe50860","unresolved":false,"context_lines":[{"line_number":11,"context_line":"a GET or HEAD to the object."},{"line_number":12,"context_line":""},{"line_number":13,"context_line":"SLOs that were created on previous versions of Swift will still have the"},{"line_number":14,"context_line":"etag of the manifest in container listings."},{"line_number":15,"context_line":""},{"line_number":16,"context_line":"Change-Id: I67478923619b00ec1a37d56b6fec6a218453dafc"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":2,"id":"1aa78d24_1a7b738d","line":14,"updated":"2016-07-06 17:43:59.000000000","message":"this part is worrisome\n\nIs this because the manifest of the stored etag is for the translated \"raw\" form or whatever it\u0027s called?","commit_id":"4157f851aee9b7079c160aa125f5005c1083c424"},{"author":{"_account_id":15343,"name":"Tim Burke","email":"tburke@nvidia.com","username":"tburke"},"change_message_id":"907da4348712c0ac5d76aa259d300d452af44d6e","unresolved":false,"context_lines":[{"line_number":11,"context_line":"a GET or HEAD to the object."},{"line_number":12,"context_line":""},{"line_number":13,"context_line":"SLOs that were created on previous versions of Swift will still have the"},{"line_number":14,"context_line":"etag of the manifest in container listings."},{"line_number":15,"context_line":""},{"line_number":16,"context_line":"Change-Id: I67478923619b00ec1a37d56b6fec6a218453dafc"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":2,"id":"1aa78d24_06067e1c","line":14,"in_reply_to":"1aa78d24_1a7b738d","updated":"2016-07-06 18:50:07.000000000","message":"Yup, prior to this we let the real MD5-of-the-object-on-disk populate the container listings. The only reason that we can get around it now is the use of X-Object-Sysmeta-Container-Update-Override-Etag (introduced in https://review.openstack.org/#/c/317475/ I believe), and there\u0027s no way to set that for pre-existing objects.\n\nIf users really care, they can COPY affected SLOs to themselves (with the \u0027?multipart-manifest\u003dget\u0027 query param to copy the manifest rather than the data).\n\nWe might be able to have the auditor go digging and adding that bit of sysmeta, but I have several reservations:\n\n- That means plumbing SLO-logic down into the auditor. *Maybe* this would be palatable with Sam\u0027s audit-watchers work, but I vastly prefer having that logic isolated to middleware/slo.py (with a little sprinkling in middleware/copy.py).\n- Just adding the sysmeta isn\u0027t enough. We\u0027d also need to convince the object updater to send the update and the container server to accept it. To my knowledge, this is why we needed to move things to sysmeta to begin with; when we were just sending X-Backend-Container-Update-Override-Etag and a POST update arrived before the PUT update, the container server would ignore the etag from the PUT because it already had an etag stored.\n- Even if we sorted the above out, there may be client applications that were using container listings, keeping track of changes themselves (and keeping in mind the fact that the hash didn\u0027t square with the etag of the object). Changing the current output for already-existing objects would cause all SLOs to be flagged as new when they weren\u0027t.","commit_id":"4157f851aee9b7079c160aa125f5005c1083c424"}]}