Update patch set 1

Patch Set 1: (1 inline comment)

Some thoughts (not even nits) in-line.

Patch-set: 1
Reviewer: Gerrit User 1689 <1689@4a232e18-c5a9-48ee-94c0-e04e7cca6543>
Label: Code-Review=0
Label: Workflow=0

81a3267ea6d7dcf41a6eeb7a062592a3735bfb9f

@@ -0,0 +1,21 @@
+{
+  "comments": [
+    {
+      "key": {
+        "uuid": "AAAAXH//vLk\u003d",
+        "filename": "specs/juno/l3-svcs-vendor-validation.rst",
+        "patchSetId": 1
+      },
+      "lineNbr": 54,
+      "author": {
+        "id": 1689
+      },
+      "writtenOn": "2014-04-17T20:04:02Z",
+      "side": 1,
+      "message": "Just some thoughts to consider, not necessarily anything that has to be changed in this BP:\n\nThese phases seem to me to be somewhat similar to the ML2 core plugin\u0027s pattern of invoking precommit() and postcommit() operations on the mechanism drivers for each create, update, and delete operation. But ML2 uses only two phases. It\u0027s precommit() is called within the DB transaction, and encompasses both the validate and persist steps being proposed here. Exceptions thrown from precommit() methods by drivers result in the entire transaction being rolled back and an exception returned to the client. ML2\u0027s postcommit() happens after the transaction has been committed, and seems to correspond to your apply phase.\n\nYou may want to reconsider whether the validate and persist phases need to be separate methods. One thing that unifying these allows is for \"validation\" to include reserving any needed resources from pools at the DB level.\n\nIf you do decide that two phases at the driver level is sufficent, and the semantics of the driver methods you end up with match those in ML2, I\u0027d recommend trying to keep the method naming and other details consistent with ML2 as well.",
+      "revId": "81a3267ea6d7dcf41a6eeb7a062592a3735bfb9f",
+      "serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
+      "unresolved": false
+    }
+  ]
+}