Update patch set 4

Patch Set 4:

(1 comment)

Patch-set: 4

6aeec08df09662a289b7ef8a59d79a3c00dd3d8d

@@ -88,6 +88,29 @@
       "revId": "6aeec08df09662a289b7ef8a59d79a3c00dd3d8d",
       "serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
     },
+    {
+      "unresolved": true,
+      "key": {
+        "uuid": "5ee248dd_a4848ef4",
+        "filename": "specs/approved/mercury.rst",
+        "patchSetId": 4
+      },
+      "lineNbr": 153,
+      "author": {
+        "id": 11655
+      },
+      "writtenOn": "2024-05-04T13:55:07Z",
+      "side": 1,
+      "message": "So digging into this, it looks more like the interface would end up with more a distinct attach/detach model, and not a direct proxy-through for ml2.\n\nSpecifically because I\u0027ve uncovered a couple cases where n-g-s does \"remote\" calls. They aren\u0027t actually remote, but the plugin directly calls a method on the provided input context, and in a couple cases interacts with neutron\u0027s DB. In both cases, it is not great.\n\nAn example is bind port, it doesn\u0027t actually engage the switch mechanism driver to do anything, it more so does checks, asks questions like \"is_link_valid\", and \"is_port_supported\", and then updates the DB. This could *entirely* be run client side with the \"is_link_valid\" and \"is_port_supported\" calls being passed through.",
+      "range": {
+        "startLine": 144,
+        "startChar": 0,
+        "endLine": 153,
+        "endChar": 59
+      },
+      "revId": "6aeec08df09662a289b7ef8a59d79a3c00dd3d8d",
+      "serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
+    },
     {
       "unresolved": true,
       "key": {