Update patch set 5

Patch Set 5:

(2 comments)

Patch-set: 5

c200c8997fcb05b817902c6c70a69c0b11152a04

@@ -118,6 +118,54 @@
       "serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
       "unresolved": false
     },
+    {
+      "key": {
+        "uuid": "5ff73747_df0d88e8",
+        "filename": "specs/newton/address-scope-subnet-pool-mapping.rst",
+        "patchSetId": 5
+      },
+      "lineNbr": 273,
+      "author": {
+        "id": 1689
+      },
+      "writtenOn": "2017-04-29T17:27:27Z",
+      "side": 1,
+      "message": "I recommend we eliminate, or at least quit using, the L3P\u0027s ip_pool DB column, and not add a similar ip_pools column if we end up adding an ip_pools attribute to the L3P API.\n\nWe are describing the ip_pool (or ip_pools) attribute as reflecting the set of IP prefixes currently used by the L3P. But any update to the prefixes attribute of any of the subnetpools used by the L3P would mean the value stored in the ip_pool(s) DB column when the L3P was created id no longer correct. We need either a way to keep the ip_pool(s) DB column up to date, or to avoid using the DB and generate the ip_pool(s) attribute value on demand.\n\nWe could try to somehow intercept updates to subnetpools at the Neutron level, find all the L3Ps that reference the subnetpool, and update the ip_pool(s) DB column of those L3Ps. But this more tightly couples the apic_aim mechanism driver with the aim_mapping policy driver, which we\u0027ve been trying to avoid. If we need to do  it, it might best be done in a separate aim_gbp_mapping Neutron mechanism driver. I will acknowledge that we already have a list of things like this where GBP really should be intercepting and handling or preventing Neutron-level API update requests. But I don\u0027t think this is a case where we have any reason to reject the Neutron update request.\n\nIt seems preferable to avoid the problem (at least for this case) by just building the ip_pool(s) value each time its needed in the _make_l3_policy_dict method using a DB query. This would require a simple query for the subnetpools referenced by the L3P, and then merging together their prefixes. In fact, it might be possible to use a sqlalchemy relationship to ensure all the subnetpool DB model objects are returned from the same query that returned the L3P DB model object, and can be accessed via a list that model object.",
+      "parentUuid": "5ff73747_4722d4ba",
+      "range": {
+        "startLine": 273,
+        "startChar": 34,
+        "endLine": 273,
+        "endChar": 45
+      },
+      "revId": "c200c8997fcb05b817902c6c70a69c0b11152a04",
+      "serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
+      "unresolved": false
+    },
+    {
+      "key": {
+        "uuid": "5ff73747_1f3ad097",
+        "filename": "specs/newton/address-scope-subnet-pool-mapping.rst",
+        "patchSetId": 5
+      },
+      "lineNbr": 273,
+      "author": {
+        "id": 1689
+      },
+      "writtenOn": "2017-04-29T17:27:27Z",
+      "side": 1,
+      "message": "This seems potentially workable. See below on the DB column.",
+      "parentUuid": "5ff73747_b80b0028",
+      "range": {
+        "startLine": 273,
+        "startChar": 34,
+        "endLine": 273,
+        "endChar": 45
+      },
+      "revId": "c200c8997fcb05b817902c6c70a69c0b11152a04",
+      "serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543",
+      "unresolved": false
+    },
     {
       "key": {
         "uuid": "5ff73747_04e9737e",