Update patch set 3

Patch Set 3: (6 comments) Patch-set: 3 Attention: {"person_ident":"Gerrit User 11628 \u003c11628@4a232e18-c5a9-48ee-94c0-e04e7cca6543\u003e","operation":"ADD","reason":"\u003cGERRIT_ACCOUNT_32755\u003e replied on the change"} Attention: {"person_ident":"Gerrit User 32755 \u003c32755@4a232e18-c5a9-48ee-94c0-e04e7cca6543\u003e","operation":"REMOVE","reason":"\u003cGERRIT_ACCOUNT_32755\u003e replied on the change"}
2022-08-25 12:48:22 +00:00 · 2022-08-25 12:48:22 +00:00 · bd08ab9b69
parent c817c9f59d
commit bd08ab9b69
3 changed files with 113 additions and 0 deletions
--- a/18
+++ b/18
@ -157,6 +157,24 @@
      "revId": "18d3f53fa4c4787cf15f0bf08d32fe8882135cdc",
      "serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
    },
+    {
+      "unresolved": false,
+      "key": {
+        "uuid": "bad37ddc_92f02bfc",
+        "filename": "specs/zed/catalog-zones.rst",
+        "patchSetId": 1
+      },
+      "lineNbr": 75,
+      "author": {
+        "id": 32755
+      },
+      "writtenOn": "2022-08-25T12:48:22Z",
+      "side": 1,
+      "message": "Ack",
+      "parentUuid": "20e006fe_06165039",
+      "revId": "18d3f53fa4c4787cf15f0bf08d32fe8882135cdc",
+      "serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
+    },
    {
      "unresolved": true,
      "key": {
--- a/53
+++ b/53
@ -52,6 +52,23 @@
      "revId": "9c25eaa6006189942593f819ef54e0d9284b5021",
      "serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
    },
+    {
+      "unresolved": false,
+      "key": {
+        "uuid": "897b2dac_7c377287",
+        "filename": "/PATCHSET_LEVEL",
+        "patchSetId": 3
+      },
+      "lineNbr": 0,
+      "author": {
+        "id": 32755
+      },
+      "writtenOn": "2022-08-25T12:48:22Z",
+      "side": 1,
+      "message": "Thanks Michael for your review and remarks! Sorry it took me a while to respond again.\n\nI\u0027d love to have a more real time exchange to add the missing bits and pieces to this spec. Maybe there is time and space at the upcoming PTG to talk about this feature / spec?",
+      "revId": "9c25eaa6006189942593f819ef54e0d9284b5021",
+      "serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
+    },
    {
      "unresolved": true,
      "key": {
@ -86,6 +103,24 @@
      "revId": "9c25eaa6006189942593f819ef54e0d9284b5021",
      "serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
    },
+    {
+      "unresolved": true,
+      "key": {
+        "uuid": "8326c9ac_27570364",
+        "filename": "specs/zed/catalog-zones.rst",
+        "patchSetId": 3
+      },
+      "lineNbr": 98,
+      "author": {
+        "id": 32755
+      },
+      "writtenOn": "2022-08-25T12:48:22Z",
+      "side": 1,
+      "message": "First of the catalog zone is clearly intended to implement the upcoming standard for managing fleets of secondaries. This spec only proposes to add this as an additional way for Designate to integrate with backends. An operator clearly has the choice to use drivers and proactive provisioning via those still.\n\nAs for the performance comparison of the two approaches:\n\nI\u0027d argue that the active (push provisioning) approach does allow Designate to do an explicit call of e.g. \"rndc addzone\" and does know when this has happened. But with all the events + RPC + call of the binary on each secondary happening, is this really faster or even more robust than just updating a zone and pushing out a NOTIFY to the secondaries?\n\nIf I may quite bluntly just quote the BIND9 documentation at https://bind9.readthedocs.io/en/v9_16_7/advanced.html#principle-of-operation:\n\n```\n5.14.1. Principle of Operation\n\nNormally, if a zone is to be served by a secondary server, the named.conf file on the server must list the zone, or the zone must be added using rndc addzone. In environments with a large number of secondary servers, and/or where the zones being served are changing frequently, the overhead involved in maintaining consistent zone configuration on all the secondary servers can be significant.\n\nA catalog zone is a way to ease this administrative burden: it is a DNS zone that lists member zones that should be served by secondary servers. When a secondary server receives an update to the catalog zone, it adds, removes, or reconfigures member zones based on the data received.\n```\n\nTo me the approach of only providing the data in a catalog zone and then sending out a notification is much more lightweight Designate or any other controller centrally providing DNS data. Image not just a single zone being added, but having e.g. a new server added to the secondaries which needs to have all the zones added. If I may point you to my post on the ML (https://lists.openstack.org/pipermail/openstack-discuss/2022-May/028484.html) about secondaries getting \"out of sync\" or being \"cold started\" with the list of domains / zones.\n\nYes, one can do a reconciliation via \"designate-manage pool update\". But this needs to be done for each and EVERY zone. This clearly does not scale well. Depending on the DNS implementation on the backend, it\u0027s likely much more efficient to use the built-in and more and more standardized mechanism to add a ton of zones, than to have hundreds or thousands of binary calls via some admin tool.\n\nLast but not least, when a user adds a zone or records Designate still has all the capabilities to check the backends have converged prior to changing a zone or record status from PENDING to ACTIVE.",
+      "parentUuid": "7bfeeba3_cce2c0af",
+      "revId": "9c25eaa6006189942593f819ef54e0d9284b5021",
+      "serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
+    },
    {
      "unresolved": true,
      "key": {
@ -136,6 +171,24 @@
      "message": "I disagree that there is no alternative. We are doing zone management today via an alternative mechanism.",
      "revId": "9c25eaa6006189942593f819ef54e0d9284b5021",
      "serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
+    },
+    {
+      "unresolved": true,
+      "key": {
+        "uuid": "e7694f03_d1177130",
+        "filename": "specs/zed/catalog-zones.rst",
+        "patchSetId": 3
+      },
+      "lineNbr": 114,
+      "author": {
+        "id": 32755
+      },
+      "writtenOn": "2022-08-25T12:48:22Z",
+      "side": 1,
+      "message": "Thats likely a loss in translation. I did not actually mean \"alternative to get the job of managing secondary DNS servers done\". That cleanly has many ways and approaches. I meant that it\u0027s either about also supporting this particular mechanism or not.",
+      "parentUuid": "411992ac_56af94fc",
+      "revId": "9c25eaa6006189942593f819ef54e0d9284b5021",
+      "serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
    }
  ]
 }
--- a/42
+++ b/42
@ -257,6 +257,30 @@
      "revId": "c45bdd4716468b0497afc86079ccc19bdf4f03ea",
      "serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
    },
+    {
+      "unresolved": true,
+      "key": {
+        "uuid": "9282960d_9814f443",
+        "filename": "specs/zed/catalog-zones.rst",
+        "patchSetId": 2
+      },
+      "lineNbr": 70,
+      "author": {
+        "id": 32755
+      },
+      "writtenOn": "2022-08-25T12:48:22Z",
+      "side": 1,
+      "message": "This is actually not how I meant the \"each and every zone\" part. \n\nI was more about the need for the worker to use the rndc binary at least once for each and every zone - https://opendev.org/openstack/designate/src/commit/5d5d83e511acbf5d6f34e9a998ff16d96c5bb162/designate/backend/impl_bind9.py#L152 to have them all reconciled / ensure to be synced.\n\nWith a catalog zone this can be done via NOTIFY and the bind9 slaves doing an AXFR of the catalog, if the \"catalog\" feature is switch on for a particular pool.",
+      "parentUuid": "d7a6e54f_32cba7a3",
+      "range": {
+        "startLine": 70,
+        "startChar": 24,
+        "endLine": 70,
+        "endChar": 35
+      },
+      "revId": "c45bdd4716468b0497afc86079ccc19bdf4f03ea",
+      "serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
+    },
    {
      "unresolved": true,
      "key": {
@ -485,6 +509,24 @@
      "revId": "c45bdd4716468b0497afc86079ccc19bdf4f03ea",
      "serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
    },
+    {
+      "unresolved": true,
+      "key": {
+        "uuid": "29b8aedb_56d5bf36",
+        "filename": "specs/zed/catalog-zones.rst",
+        "patchSetId": 2
+      },
+      "lineNbr": 93,
+      "author": {
+        "id": 32755
+      },
+      "writtenOn": "2022-08-25T12:48:22Z",
+      "side": 1,
+      "message": "I totally agree TSIG to protect access to the catalog is the way to go.\nBut isn\u0027t this already implemented for (other) AXFRs, see https://opendev.org/openstack/designate/search?q\u003dquery_enforce_tsig\n\nIf the catalog zone relates to a pool, as in it provides the list of zones a pool is responsible for, why not use the existing scope \"pool\" for TSIG keys?\n* https://docs.openstack.org/api-ref/dns/?expanded\u003dcreate-tsigkeys-detail#id136\n\nThe handler also already checks the scope - https://opendev.org/openstack/designate/src/commit/d05232fc075ffe6bfaf7a537334fe081bb41a65c/designate/mdns/handler.py#L192\n\nAny a catalog zone should \"require\" a pool scoped TSIG, as this is the amount / scope of data returned ...",
+      "parentUuid": "a1ce3042_5e4f04d3",
+      "revId": "c45bdd4716468b0497afc86079ccc19bdf4f03ea",
+      "serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
+    },
    {
      "unresolved": true,
      "key": {