openstack
/
designate-specs
Code Issues Proposed changes

Update patch set 8 

Patch Set 8:

(1 comment)

Patch-set: 8
Attention: {"person_ident":"Gerrit User 11628 \u003c11628@4a232e18-c5a9-48ee-94c0-e04e7cca6543\u003e","operation":"REMOVE","reason":"\u003cGERRIT_ACCOUNT_11628\u003e replied on the change"}
Attention: {"person_ident":"Gerrit User 32755 \u003c32755@4a232e18-c5a9-48ee-94c0-e04e7cca6543\u003e","operation":"ADD","reason":"\u003cGERRIT_ACCOUNT_11628\u003e replied on the change"}
This commit is contained in:
Gerrit User 11628 2023-01-20 19:32:49 +00:00 committed by Gerrit Code Review
parent 79a22c1273
commit f29d0173de
1 changed files with 18 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

18
bbc663b4fbb35e0c9cade9d50c0f0b1133ecee38
View File

@ -226,6 +226,24 @@
"parentUuid": "fd987fa9_da1a9e77",
"revId": "bbc663b4fbb35e0c9cade9d50c0f0b1133ecee38",
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
},
{
"unresolved": true,
"key": {
"uuid": "dcafd166_c72fc3c6",
"filename": "specs/antelope/catalog-zones.rst",
"patchSetId": 8
},
"lineNbr": 91,
"author": {
"id": 11628
},
"writtenOn": "2023-01-20T19:32:49Z",
"side": 1,
"message": "Hi, comment by section.\n\na) Yes, \"Storage Changes\" section 5 and \"Other Changes\" section 1 talk to the new settings required in pools.yaml that will be loaded at pools update time. So, the same pools.yaml update process, but with optional additional config settings to enable a catalog zone for the pool. I will post a spin with the added pool_attributes update I missed in the last draft.\n\nb) To clarify, this schema version is for the catalog zone format[1] and not related to the pools.yaml. Currently the only valid version is \"2\" per the catalog zone spec. From a Designate perspective, this value would only change if the code that renders the catalog zone is changed to support a new RFC schema version (I.e. what TXT records are required/available, etc.). So, frankly, this could be a constant value for now that would be included in the catalog zone (per the spec) and display for convenience in the zone record. The version field of a zone record must have a value in the database, so I was proposing to use the catalog zone schema version to meet that requirement. If/when another schema is defined, this could can be updated to support multiple schema as needed, potentially per pool if different backends support different schema versions. For simplicity here, I think we can just use \"2\" for now and address the additional functionality in a future patch.\n\nd) The serial number topic is a complicated one, with multiple proposals as you have commented. I think for this spec I don\u0027t want it to get hung up on those parallel discussions. My proposal is we implement the current \"naive increment\" mechanism used for zone serial numbers. We would increment and send a notify for the catalog zone using the same mechanisms we do for the zone itself. This would trigger on zone create/update/delete. I will add a section in the spec for this as well. This would defer a better serial mechanism to a future patch once we agree on the best approach. The good news is catalog zones are not as likely to change as fast as zones with recordsets.\n\n[1] https://www.ietf.org/archive/id/draft-ietf-dnsop-dns-catalog-zones-08.html#section-4.3.1",
"parentUuid": "c800dc70_4fdd767b",
"revId": "bbc663b4fbb35e0c9cade9d50c0f0b1133ecee38",
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
}
]
}