Update patch set 5

Patch Set 5:

(1 comment)

Patch-set: 5

e19645628b53601fe3803c2edb6296d03e8a811f

@@ -897,6 +897,24 @@
       "serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
       "unresolved": false
     },
+    {
+      "key": {
+        "uuid": "3ae8d1ca_bd3f9bd5",
+        "filename": "specs/juno/tuskar-rest-api.rst",
+        "patchSetId": 5
+      },
+      "lineNbr": 231,
+      "author": {
+        "id": 8399
+      },
+      "writtenOn": "2014-05-28T15:15:44Z",
+      "side": 1,
+      "message": "I couldn\u0027t decide where to put this, in response to this comment or the next batch, so realize it kinda applies to both.\n\nThe problem is, even if Tuskar doesn\u0027t proxy the call, someone needs to take into account the fact that there are two separate deletes happening and correlate them. If we say that Tuskar doesn\u0027t do any of the proxying, then it\u0027s on the client layer to resolve what happens for a partial success, which is really bad (especially for a short-lived process like a CLI who has no state whatsoever in which to remember something bombed and retry it later).\n\nI\u0027ve hesitated to talk too much about having an internal tasking system in Tuskar, but given the sorts of questions that are arising, it might be prudent to start to design it out more explicitly.",
+      "parentUuid": "3ae8d1ca_e7699e8c",
+      "revId": "e19645628b53601fe3803c2edb6296d03e8a811f",
+      "serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
+      "unresolved": false
+    },
     {
       "key": {
         "uuid": "3ae8d1ca_d7b554ce",