)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":13252,"name":"Dr. Jens Harbott","display_name":"Jens Harbott (frickler)","email":"frickler@offenerstapel.de","username":"jrosenboom"},"change_message_id":"20716b76d3d2b7d5f31f10ddb40fe9370c99d75b","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"c5fa634c_4796f114","updated":"2022-07-11 09:07:18.000000000","message":"Interesting feature, I hadn\u0027t heard about it before. Seems pretty new though, so in general I\u0027m not sure whether it would be stable enough already to support it.","commit_id":"18d3f53fa4c4787cf15f0bf08d32fe8882135cdc"},{"author":{"_account_id":32755,"name":"Christian Rohmann","email":"christian.rohmann@inovex.de","username":"frittentheke"},"change_message_id":"d88b92407e684c15edd3ed03bba57c5cd01c5fa8","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"df4a6b54_44246820","updated":"2022-07-11 08:34:15.000000000","message":"Please kindly take a look to the idea of adding catalog zones which could be a huge improvement on Designate\u0027s capabilities to provision secondary name servers.","commit_id":"18d3f53fa4c4787cf15f0bf08d32fe8882135cdc"},{"author":{"_account_id":32755,"name":"Christian Rohmann","email":"christian.rohmann@inovex.de","username":"frittentheke"},"change_message_id":"bab52ac87a722751ed5155097cfd304d525232da","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"8dbaebf8_7f9be865","updated":"2022-07-11 12:51:15.000000000","message":"Thanks for the quick response - See me comments inline.\n\nI certainly would love to discuss this idea, spec and potential implementation during a weekly meeting or PTG if there are any happening (https://wiki.openstack.org/wiki/Meetings/Designate).","commit_id":"18d3f53fa4c4787cf15f0bf08d32fe8882135cdc"},{"author":{"_account_id":32755,"name":"Christian Rohmann","email":"christian.rohmann@inovex.de","username":"frittentheke"},"change_message_id":"bab52ac87a722751ed5155097cfd304d525232da","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"98cf12d9_4af81535","in_reply_to":"c5fa634c_4796f114","updated":"2022-07-11 12:51:15.000000000","message":"I ran into it when I dove into the issue of \"resilvering\" a secondary server (BIND9) with all the domains it should know about (see my post to the ML https://lists.openstack.org/pipermail/openstack-discuss/2022-May/028484.html).\n\nOnce you know what to search for, as in the terms \"catalog domain\", it seems quite widespread already and to have received quite some traction among DNS servers implementation in order to be able to use catalog zones for their provisioning. If you look at my referenced implementations it seems that all \"relevant\" DNS servers mention it in some way or other and BIND9 and Knot do have this feature for a while now. \n\nWhile not actually heling my point ... if you look at e.g. https://github.com/IETF-Hackathon/NSDCatZ/ or https://github.com/PowerDNS/powercatz/ there also is potential to use catalog zones on servers not natively supporting them, yet. With data transfer and happening only via DNS this is much less complex as in doing API queries and pagination to Designate.\n\nNot to become too philosophical, but to me the success of an interface or process depends certainly on its quality first. But also on the adoptions on both ends.\n\nMy point is that with BIND9 and Knot supporting being a client / consumer in their production code, that is a good reason to start supporting this in Designate as a provider / primary server.","commit_id":"18d3f53fa4c4787cf15f0bf08d32fe8882135cdc"},{"author":{"_account_id":11628,"name":"Michael Johnson","email":"johnsomor@gmail.com","username":"johnsom"},"change_message_id":"97b457ae6a193a9771f792d0538f0edd06fe7840","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"50635e54_81cfc3c2","updated":"2022-07-13 21:13:15.000000000","message":"I have a few comments and areas I think we need to investigate more.\nAlso, can you please migrate this back to the template format so we have all of the sections?\nThanks!","commit_id":"c45bdd4716468b0497afc86079ccc19bdf4f03ea"},{"author":{"_account_id":32755,"name":"Christian Rohmann","email":"christian.rohmann@inovex.de","username":"frittentheke"},"change_message_id":"7e97dcd7f1ac3610a3bc1877c472216c98294a4a","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":2,"id":"e3fd642d_bc454cdc","updated":"2022-07-14 11:52:21.000000000","message":"Thanks again Michael for your time, thoughts and good feedback.\n\nMay I second my proposal to discuss this feature in some sort of real-time manner to jointly go through the missing issues and exchange implementation ideas?\n\nI guess you already read through my proposal that I strongly believe this is an awesome feature to have as it removed lots of logic and code paths that Designate needs to deal with otherwise and opens up to much easier integration of more backends.\n\nThere certainly is reasoning behind the multiple DNS server implementations, BIND9 likely being the most prominent one, having support for this and the work at the IETF to make this a RFC.","commit_id":"c45bdd4716468b0497afc86079ccc19bdf4f03ea"},{"author":{"_account_id":11628,"name":"Michael Johnson","email":"johnsomor@gmail.com","username":"johnsom"},"change_message_id":"c817c9f59d18e2be850be2aba8b4f376574cff08","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"90282f86_75b80ed9","updated":"2022-08-10 21:00:51.000000000","message":"A few more things we need to design and capture for the spec.","commit_id":"9c25eaa6006189942593f819ef54e0d9284b5021"},{"author":{"_account_id":32755,"name":"Christian Rohmann","email":"christian.rohmann@inovex.de","username":"frittentheke"},"change_message_id":"cd495e99b073e40471ecab911386d7fff2907363","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"8e865e06_2774e982","updated":"2022-08-04 11:57:47.000000000","message":"Hey there. Could we maybe pick up on the discussion about this spec somehow?\nI\u0027d love to have this added to Designate.\n\nMaybe it does makes sense to agree on a time and virtual space to meet and discuss?","commit_id":"9c25eaa6006189942593f819ef54e0d9284b5021"},{"author":{"_account_id":5572,"name":"Don Kehn","display_name":"DEKehn","email":"dekehn@gmail.com","username":"dekehn"},"change_message_id":"a8c5e807653896d94dfa09dca7096bfb8f13ae39","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"b6c7a57c_9b63c29b","updated":"2022-11-03 20:43:54.000000000","message":"Is it safe to assume, included in this spec we would also implement incremental zone transfers (IXFR)? During the PTG if I understand the problem case that was stated, is that the zone transfers for a extremely large deployments take too long and the size of data being transferred is pretty large. Are we considering incremental zone transfers in this spec as well? Should we? ","commit_id":"9c25eaa6006189942593f819ef54e0d9284b5021"},{"author":{"_account_id":5572,"name":"Don Kehn","display_name":"DEKehn","email":"dekehn@gmail.com","username":"dekehn"},"change_message_id":"1dacdcf18f42f072c755deb9fc0fd5cc73afc45b","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"c1d1a53c_81963541","updated":"2022-11-12 15:47:24.000000000","message":"LGTM - my comments have been answered.","commit_id":"9c25eaa6006189942593f819ef54e0d9284b5021"},{"author":{"_account_id":11628,"name":"Michael Johnson","email":"johnsomor@gmail.com","username":"johnsom"},"change_message_id":"9a7d934cfb359f34260561c56ab91d00bce94949","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"3aefaa96_1a0b063a","updated":"2022-10-20 14:49:47.000000000","message":"Let\u0027s try to merge this by Antelope MS1","commit_id":"9c25eaa6006189942593f819ef54e0d9284b5021"},{"author":{"_account_id":32755,"name":"Christian Rohmann","email":"christian.rohmann@inovex.de","username":"frittentheke"},"change_message_id":"2840523a867513d8f55a5ec51ec57022eba15355","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"bf91b06a_93a6aece","updated":"2022-10-26 10:05:30.000000000","message":"Michael, is there anything you\u0027d expect from my side to be done here?\nOr will you be adding all details that might be missing here?","commit_id":"9c25eaa6006189942593f819ef54e0d9284b5021"},{"author":{"_account_id":32755,"name":"Christian Rohmann","email":"christian.rohmann@inovex.de","username":"frittentheke"},"change_message_id":"e9f83a9ea3a32e0308f729b614fb8c592a8894e4","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"26e30985_8207a801","updated":"2022-08-31 09:29:07.000000000","message":"Sorry for the laggy reply - as said, please let me know when/where/how to join the discussion about this at the PTG.","commit_id":"9c25eaa6006189942593f819ef54e0d9284b5021"},{"author":{"_account_id":32755,"name":"Christian Rohmann","email":"christian.rohmann@inovex.de","username":"frittentheke"},"change_message_id":"bd08ab9b691e055663c645a37281ed790889d65b","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"897b2dac_7c377287","updated":"2022-08-25 12:48:22.000000000","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?","commit_id":"9c25eaa6006189942593f819ef54e0d9284b5021"},{"author":{"_account_id":11628,"name":"Michael Johnson","email":"johnsomor@gmail.com","username":"johnsom"},"change_message_id":"a38aa668a4daf880d6106c4dfac7a88ba9346154","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"ed8b2d3d_7d697400","in_reply_to":"26e30985_8207a801","updated":"2022-09-08 22:17:13.000000000","message":"Here is our etherpad for the PTG: https://etherpad.opendev.org/p/oct2022-ptg-designate.\nLet me know if starting earlier or later in the timeslot would work best for you.","commit_id":"9c25eaa6006189942593f819ef54e0d9284b5021"},{"author":{"_account_id":32755,"name":"Christian Rohmann","email":"christian.rohmann@inovex.de","username":"frittentheke"},"change_message_id":"f42b96e217942fcc5097d633b7449517e0f0a943","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":3,"id":"2f9b462c_0c5e397e","in_reply_to":"3aefaa96_1a0b063a","updated":"2022-11-11 08:37:34.000000000","message":"Michael, MS1 is now just 6 days away. Is there anything I could add / help with to get this accepted and merged?","commit_id":"9c25eaa6006189942593f819ef54e0d9284b5021"},{"author":{"_account_id":11628,"name":"Michael Johnson","email":"johnsomor@gmail.com","username":"johnsom"},"change_message_id":"f08c86dd084ce4225ad0eaae2017fa212f7f9799","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"96cba2bf_7effccc9","in_reply_to":"897b2dac_7c377287","updated":"2022-08-29 21:13:30.000000000","message":"Yes, I think this is a great topic for the PTG. I will make sure to create a time slot for it.\nTo help schedule the PTG sessions, what timezone are you in?","commit_id":"9c25eaa6006189942593f819ef54e0d9284b5021"},{"author":{"_account_id":11628,"name":"Michael Johnson","email":"johnsomor@gmail.com","username":"johnsom"},"change_message_id":"c817c9f59d18e2be850be2aba8b4f376574cff08","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"208f079a_84f483ba","in_reply_to":"8e865e06_2774e982","updated":"2022-08-10 21:00:51.000000000","message":"Hi,\nMentioning this in the #openstack-dns channel will help remind people there are new comments. We can also bring this up at the PTG if it is not merged by then.","commit_id":"9c25eaa6006189942593f819ef54e0d9284b5021"},{"author":{"_account_id":32755,"name":"Christian Rohmann","email":"christian.rohmann@inovex.de","username":"frittentheke"},"change_message_id":"e9f83a9ea3a32e0308f729b614fb8c592a8894e4","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"b5d19dc0_9e8dcd63","in_reply_to":"96cba2bf_7effccc9","updated":"2022-08-31 09:29:07.000000000","message":"I am in CET (Europe/Berlin). Please kindly let me know when you picked a timeslot so I can see if that works for me or at least block that in my calendar.","commit_id":"9c25eaa6006189942593f819ef54e0d9284b5021"},{"author":{"_account_id":32755,"name":"Christian Rohmann","email":"christian.rohmann@inovex.de","username":"frittentheke"},"change_message_id":"1979a38036be3816524e62b5f0d6563f9fddfe15","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":3,"id":"9fab7c91_ae24490b","in_reply_to":"b6c7a57c_9b63c29b","updated":"2022-11-04 11:44:18.000000000","message":"First of all the issue with large deployments (lots of zones) is that some admin tool (rndc addzone/modzone in the case of BIND) is called on all secondaries - individually for each zone (see https://opendev.org/openstack/designate/src/commit/5d5d83e511acbf5d6f34e9a998ff16d96c5bb162/designate/backend/impl_bind9.py#L152). \n\nThe catalog zone on the contrary will \"just\" be a list that the secondary can slurp in (after being notified about it) and do so in one go internally. The zone transfers for each domain from the mini DNS will then happen just like as they are now. So in essence this is about getting the zones setup / removed on the secondaries efficiently.\n\nSo regarding IXFR, are you mean for the catalog zone itself? Well I doubt that there is an immediate scaling issue there - but frankly mdns does not support IXFR any zone, see this comment in the handler: https://opendev.org/openstack/designate/src/commit/0b162a4c48ff7806ee0dda0f871a884a32374ed9/designate/mdns/handler.py#L69\n\n\nSo if IXFR would be implemented, it will certainly help the transfer efficiency of both the catalog and the zone data, but to be that seems out of scope for this spec?","commit_id":"9c25eaa6006189942593f819ef54e0d9284b5021"},{"author":{"_account_id":32755,"name":"Christian Rohmann","email":"christian.rohmann@inovex.de","username":"frittentheke"},"change_message_id":"4eb1f8fa920a27fe0113ca3fee2f7497452ddfee","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"0a69f133_966b6d73","in_reply_to":"ed8b2d3d_7d697400","updated":"2022-09-21 13:27:22.000000000","message":"\u003e Here is our etherpad for the PTG: https://etherpad.opendev.org/p/oct2022-ptg-designate.\n\u003e Let me know if starting earlier or later in the timeslot would work best for you.\n\nSorry I almost missed this comment ... Thanks for scheduling \"me\" in.\nEarlier in the timeslot would be better for me.","commit_id":"9c25eaa6006189942593f819ef54e0d9284b5021"},{"author":{"_account_id":32755,"name":"Christian Rohmann","email":"christian.rohmann@inovex.de","username":"frittentheke"},"change_message_id":"59994d09b5b890521f2ee0cf317d1c8dda8dab3e","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":5,"id":"0543ad6b_c968a707","updated":"2022-11-15 15:09:08.000000000","message":"I rebased this to get rid of the merge conflict and also moved the spec to Antelope.\n\n\nFTAL - Would love to start discussing the implementation ;-)\n","commit_id":"3dfdb4d574500f03724191afa712b53c916e586b"},{"author":{"_account_id":11628,"name":"Michael Johnson","email":"johnsomor@gmail.com","username":"johnsom"},"change_message_id":"68d39ba15b9559bd1208a1afa92fd09ae5bcbb85","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":8,"id":"984779e5_052566ce","updated":"2022-11-22 17:14:23.000000000","message":"Christian, Do my revisions align to your vision/use case? Please feel free to leave comments and vote on the spec code review.\nI would like to get your feedback before we merge this.","commit_id":"bbc663b4fbb35e0c9cade9d50c0f0b1133ecee38"},{"author":{"_account_id":32755,"name":"Christian Rohmann","email":"christian.rohmann@inovex.de","username":"frittentheke"},"change_message_id":"d555b19444f2264578149c58cd0cf8c4cea8a49d","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":8,"id":"6039f2ac_dc07d193","updated":"2023-01-17 07:51:14.000000000","message":"Could you kindly let me know what you current plans with this spec are?\nI suppose it\u0027s too late for 2023.01 / Antelope to be implemented, but maybe we could still work out the last remaining discussions / review remarks?","commit_id":"bbc663b4fbb35e0c9cade9d50c0f0b1133ecee38"},{"author":{"_account_id":32755,"name":"Christian Rohmann","email":"christian.rohmann@inovex.de","username":"frittentheke"},"change_message_id":"3a76729989460d1041c86d54cb8ef1ab5bce2bfa","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":8,"id":"e386eb17_420717be","updated":"2022-12-12 11:05:49.000000000","message":"Hey Michael,\n\nsorry I was away for a while. May I just ping you once again about the state of this spec to easy my urge to have this feature moving forward?","commit_id":"bbc663b4fbb35e0c9cade9d50c0f0b1133ecee38"},{"author":{"_account_id":32755,"name":"Christian Rohmann","email":"christian.rohmann@inovex.de","username":"frittentheke"},"change_message_id":"e7ce55ab6c20b9bafb7f17d176d5068aaa20ce2d","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":8,"id":"64954b9d_2ecc7ca3","updated":"2022-11-24 15:01:14.000000000","message":"Hey Michael, \n\nthanks for all your contributions and for picking up on this idea of having catalog zones in Designate.\n\n1) As far as the use-case goes I cannot not ask for more. As I wrote in one of my early drafts: \"You either provide a catalog zone or you don\u0027t\" :-)\n\n2) I took the liberty to discuss a bit of the actual implementation around storing the catalog vs. creating it dynamically - see below.\n\n3) Regarding implementation, what are your thoughts on timeline and working on this together?\n","commit_id":"bbc663b4fbb35e0c9cade9d50c0f0b1133ecee38"},{"author":{"_account_id":32755,"name":"Christian Rohmann","email":"christian.rohmann@inovex.de","username":"frittentheke"},"change_message_id":"79a22c12731126427d0e5469c3b832d450e45c0c","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":8,"id":"124462df_a4eb9879","updated":"2023-01-20 09:14:51.000000000","message":"I added a few more remarks, but I believe this spec is quickly approaching the final state, there ought to be something left for the implementation phase :-)\n\nMaybe another revision clarifying the storage parts (section \"a\") and maybe the catalog zone serial update mechanisms and I have no objection to apply my +1.\n\n","commit_id":"bbc663b4fbb35e0c9cade9d50c0f0b1133ecee38"},{"author":{"_account_id":5572,"name":"Don Kehn","display_name":"DEKehn","email":"dekehn@gmail.com","username":"dekehn"},"change_message_id":"e3800e04868583902e0ca19db6c859836437a1d2","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":8,"id":"97e4d4d4_9ea0907a","updated":"2022-11-21 22:50:57.000000000","message":"LGTM - see previous comments","commit_id":"bbc663b4fbb35e0c9cade9d50c0f0b1133ecee38"},{"author":{"_account_id":11628,"name":"Michael Johnson","email":"johnsomor@gmail.com","username":"johnsom"},"change_message_id":"e8d2a60e0137d24d119ed1298138028b0a71ffad","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":8,"id":"cf3b6ccc_7d15abc2","in_reply_to":"6039f2ac_dc07d193","updated":"2023-01-18 22:34:24.000000000","message":"Yes, this dropped off my radar was well with the holidays. Let me review your comments today and we can go from there.","commit_id":"bbc663b4fbb35e0c9cade9d50c0f0b1133ecee38"},{"author":{"_account_id":32755,"name":"Christian Rohmann","email":"christian.rohmann@inovex.de","username":"frittentheke"},"change_message_id":"a49117131810c2040f77973c78e957b22ed7732e","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":8,"id":"3bce5d48_84be8472","in_reply_to":"cf3b6ccc_7d15abc2","updated":"2023-01-19 07:30:45.000000000","message":"Ack","commit_id":"bbc663b4fbb35e0c9cade9d50c0f0b1133ecee38"},{"author":{"_account_id":11628,"name":"Michael Johnson","email":"johnsomor@gmail.com","username":"johnsom"},"change_message_id":"8cb3b506ce40cae5324a65a7cee5861a9d3f9e10","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":10,"id":"a2607349_e4074c11","updated":"2023-01-24 22:07:44.000000000","message":"I am good with this and the owner has commented/voted, +2","commit_id":"cbf85d69b2a627dbe98aad971635456f325426aa"},{"author":{"_account_id":11628,"name":"Michael Johnson","email":"johnsomor@gmail.com","username":"johnsom"},"change_message_id":"1c76048786cee7aa56e1b4ac41b4cef35da1e4b3","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":10,"id":"2c1ed884_674d805e","updated":"2023-02-03 22:21:00.000000000","message":"I think this is ready for merge.","commit_id":"cbf85d69b2a627dbe98aad971635456f325426aa"},{"author":{"_account_id":32755,"name":"Christian Rohmann","email":"christian.rohmann@inovex.de","username":"frittentheke"},"change_message_id":"2fa0bba9a759238f155fb2dc0af45728fea29551","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":10,"id":"d256914d_1270493d","updated":"2023-01-24 20:49:51.000000000","message":"LGTM","commit_id":"cbf85d69b2a627dbe98aad971635456f325426aa"},{"author":{"_account_id":32755,"name":"Christian Rohmann","email":"christian.rohmann@inovex.de","username":"frittentheke"},"change_message_id":"40c1ecc20a44b15a650bae3c3e1e23a6c053a43b","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":10,"id":"f7ccb619_fd7a8f18","updated":"2023-01-31 08:05:33.000000000","message":"What is the way forward with this? I suppose all that\u0027s left to do here is either wait for more +1s or 2s or hit the merge button? Or is there anyone whos opinion is missing here?\n\nIf accepted, what is the timeframe and approach to implement the catalog zones then?\n\n\nPSA: I shall be on vacation for the comming three weeks.","commit_id":"cbf85d69b2a627dbe98aad971635456f325426aa"},{"author":{"_account_id":11628,"name":"Michael Johnson","email":"johnsomor@gmail.com","username":"johnsom"},"change_message_id":"1c76048786cee7aa56e1b4ac41b4cef35da1e4b3","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":10,"id":"0938b7cb_03d63da0","in_reply_to":"f7ccb619_fd7a8f18","updated":"2023-02-03 22:21:00.000000000","message":"Hi Christian, I hope you enjoy your vacation time!\n\nSo the spec was open for review and comments for at least a week. This gives time for all of the core reviews and community to add any last votes/comments.\n\nI think at this point we can merge this as there have not been any new comments.\nOnce merged folks are open to start work on patches. We will not merge those patches until the open of the Bobcat development cycle, sometime between March 3rd and March 15th depending on the number of bug fix patches we need to get into Antelope.\nReviews on the patches can happen at any time during this process.\nI expect this will be a prioritized feature for Bobcat. We will discuss that at the virtual PTG in March.","commit_id":"cbf85d69b2a627dbe98aad971635456f325426aa"}],"specs/antelope/catalog-zones.rst":[{"author":{"_account_id":32755,"name":"Christian Rohmann","email":"christian.rohmann@inovex.de","username":"frittentheke"},"change_message_id":"b2f52895e93f4c2613860c9f53a8569289c97fa3","unresolved":true,"context_lines":[{"line_number":119,"context_line":""},{"line_number":120,"context_line":"   a. A \"catalog_zone_fqdn\" key/value will be added below the \"catalog_zone\""},{"line_number":121,"context_line":"      parent. This will be a required field if \"catalog_zone\" is specified. It"},{"line_number":122,"context_line":"      will be validated to ensure it is a valide Fully Qualified Domain Name"},{"line_number":123,"context_line":"      (fqdn)."},{"line_number":124,"context_line":"   b. A \"catalog_zone_refresh\" key/value will be added below the \"catalog_zone\""},{"line_number":125,"context_line":"      parent. This is an optional setting that will use a default of 60"}],"source_content_type":"text/x-rst","patch_set":7,"id":"57b9a1a2_2e83bf4d","line":122,"updated":"2022-11-21 12:13:52.000000000","message":"nit: \"valid\"","commit_id":"8067b6ebff1518447f0291ba405a0ad9e1e9f90f"},{"author":{"_account_id":11628,"name":"Michael Johnson","email":"johnsomor@gmail.com","username":"johnsom"},"change_message_id":"7f304da13589bfb049291e45a38e76daf8cdb79a","unresolved":false,"context_lines":[{"line_number":119,"context_line":""},{"line_number":120,"context_line":"   a. A \"catalog_zone_fqdn\" key/value will be added below the \"catalog_zone\""},{"line_number":121,"context_line":"      parent. This will be a required field if \"catalog_zone\" is specified. It"},{"line_number":122,"context_line":"      will be validated to ensure it is a valide Fully Qualified Domain Name"},{"line_number":123,"context_line":"      (fqdn)."},{"line_number":124,"context_line":"   b. A \"catalog_zone_refresh\" key/value will be added below the \"catalog_zone\""},{"line_number":125,"context_line":"      parent. This is an optional setting that will use a default of 60"}],"source_content_type":"text/x-rst","patch_set":7,"id":"ab85222e_78c755f4","line":122,"in_reply_to":"57b9a1a2_2e83bf4d","updated":"2022-11-21 20:17:59.000000000","message":"Done","commit_id":"8067b6ebff1518447f0291ba405a0ad9e1e9f90f"},{"author":{"_account_id":32755,"name":"Christian Rohmann","email":"christian.rohmann@inovex.de","username":"frittentheke"},"change_message_id":"e7ce55ab6c20b9bafb7f17d176d5068aaa20ce2d","unresolved":true,"context_lines":[{"line_number":88,"context_line":"   on the backend DNS servers if the pool has a catalog zone configured."},{"line_number":89,"context_line":""},{"line_number":90,"context_line":""},{"line_number":91,"context_line":"Storage Changes"},{"line_number":92,"context_line":"---------------"},{"line_number":93,"context_line":""},{"line_number":94,"context_line":"1. The zone database schema will need to be updated to add a new \"type\" of"}],"source_content_type":"text/x-rst","patch_set":8,"id":"30e3bd30_cb0bb9bd","line":91,"updated":"2022-11-24 15:01:14.000000000","message":"I\u0027d like to argue that while a catalog zone is technically a regular DNS zone, it\u0027s not a zone that belongs to a tenant (as you write down below). It\u0027s more of a technical vehicle to transport the list of zones. As such, maybe it would be feasible to avoid storing and maintaining it as a \"regular\" (new type \"CATALOG\") zone and treat it more like something \"virtual zone\", derived from existing data, instead of maintaining this somehow redundant data as zone:\n\n a) To enable providing a catalog zone for a pool all you need is the info that and how the zone should be presented (FQDN, TSIG, ...) all of that will be part of the pool (as you wrote in `Other Changes`).\n\n b) Then there is the \"Schema Version\" - maybe something that should go into yet another config setting of the pool? This would allow running pools with different schemas, and upgrade one by one ... when there are new schemas and Designate implements them. Via this setting only supported versions could be accepted when the pool is created or configured.\n\n c) Next is the list of zones belonging to a pool and which need to be returned - that\u0027s just one SQL SELECT to the zones table away.\n \n d) Finally we need a serial for the catalog zone and that has to reflect / update on changes to the zones of a pool. Here I\u0027d like to imagine that using someting the lines of \"SELECT MAX(\"updated_at\") FROM zones WHERE pool_id \u003d $MY_POOL_ID\" (including deleted zones) should be sufficient.\n \n \n \nMy main arguments against the new zone type is \n\na) the redundancy of the data and\nb) the requirement to restrict API operations to this kind of zone, even for admins, as it is maintained by Designate internally.","commit_id":"bbc663b4fbb35e0c9cade9d50c0f0b1133ecee38"},{"author":{"_account_id":11628,"name":"Michael Johnson","email":"johnsomor@gmail.com","username":"johnsom"},"change_message_id":"e8d2a60e0137d24d119ed1298138028b0a71ffad","unresolved":true,"context_lines":[{"line_number":88,"context_line":"   on the backend DNS servers if the pool has a catalog zone configured."},{"line_number":89,"context_line":""},{"line_number":90,"context_line":""},{"line_number":91,"context_line":"Storage Changes"},{"line_number":92,"context_line":"---------------"},{"line_number":93,"context_line":""},{"line_number":94,"context_line":"1. The zone database schema will need to be updated to add a new \"type\" of"}],"source_content_type":"text/x-rst","patch_set":8,"id":"d301ef75_63a5c6d0","line":91,"in_reply_to":"2d4ba828_51937812","updated":"2023-01-18 22:34:24.000000000","message":"Hi Christian, thank you for your comments.\n\nJust to clarify, I am not advocating maintaining recordsets in the catalog zones. As you have mentioned, I think the content of this zone can be generated based on a SQL query (as I highlighted in Storage Changes #4).\n\nLet me address the additional comments by there section identifier:\n\na) Yes, there is some information that defines a catalog zone that will be loaded from the pool.yaml and stored in the pool_attributes table (which I missed in the current spec draft storage section, Opps). However, I think it is in our best interest to still create a zone record for these catalog zones. I think some of the existing fields we track for zone are applicable to catalog zones and the management/debugging of them. For example, it will be much more straight forward to debug a missing zone transfer if the operator can make a familiar \"zone show\" call to find the current expected serial number of the zone. It will also simplify the work required to share these zones via the mini-dns and for the worker to properly handle NOTIFY messages. Given the current code base, by maintaining a zone record for these catalog zones, you will get some of this functionality for free. Along the troubleshooting lines, we also see folks that have modified the pools.yaml but forgot to run the update command. By having the catalog zones as part of the zone show/list APIs it makes debugging these situations much more simple. Finally, the other thing to note is that the cross-process/instance locking used in designate is based on the zone ID. By not having a zone record, there could be situations where catalog zone actions could result in inconsistent/unexpected results.\n\nb) The \"schema version\" is the schema of the catalog zone being sent by mini-dns, so it is not a config setting that should be included in the pool definition, but generated by the catalog zone render code. I was suggesting managing it in the zone record for coding simplicity sake and for providing a query-able value via the API.\n\nc) Correct, I tried to capture that in Storage Changes #4. Frankly, my hope is that a catalog zone transfer request would only trigger a single database query/round trip to collect all of the required data. I do however expect this query to be fairly complicated.\n\nd) It would work to calculate the MAX() of the created_at, updated_at, and deleted_ad from the zones, but this could be a complicated query for requests like \"list zones\". It also raises race condition issues with the serial number and updates that are faster than a second. We have an open patch we are discussing around moving the serial number update to a batch model[1] to help resolve this issue. Again, this may be an area where if we treat these like any other zone we are handling, it may simplify the development of the feature and reduce future issues.\n\n[1] https://review.opendev.org/c/openstack/designate/+/823325","commit_id":"bbc663b4fbb35e0c9cade9d50c0f0b1133ecee38"},{"author":{"_account_id":32755,"name":"Christian Rohmann","email":"christian.rohmann@inovex.de","username":"frittentheke"},"change_message_id":"aebb9700a44f3f3a3fc86158c285ee53a92d18d0","unresolved":true,"context_lines":[{"line_number":88,"context_line":"   on the backend DNS servers if the pool has a catalog zone configured."},{"line_number":89,"context_line":""},{"line_number":90,"context_line":""},{"line_number":91,"context_line":"Storage Changes"},{"line_number":92,"context_line":"---------------"},{"line_number":93,"context_line":""},{"line_number":94,"context_line":"1. The zone database schema will need to be updated to add a new \"type\" of"}],"source_content_type":"text/x-rst","patch_set":8,"id":"2d4ba828_51937812","line":91,"in_reply_to":"30e3bd30_cb0bb9bd","updated":"2022-11-24 15:34:45.000000000","message":"\u003e  d) Finally we need a serial for the catalog zone and that has to reflect / update on changes to the zones of a pool. Here I\u0027d like to imagine that using someting the lines of \"SELECT MAX(\"updated_at\") FROM zones WHERE pool_id \u003d $MY_POOL_ID\" (including deleted zones) should be sufficient.\n\nReading this again, I believe the updated_at field is not working in this case ..\nIt\u0027s rather the larger one of MAX(created_at) and MAX(deleted_at), right? So the \"serial\" of the catalog is the last time a zone was either deleted or created for that particular pool.","commit_id":"bbc663b4fbb35e0c9cade9d50c0f0b1133ecee38"},{"author":{"_account_id":11628,"name":"Michael Johnson","email":"johnsomor@gmail.com","username":"johnsom"},"change_message_id":"f29d0173de11b545433ac3b93caa1a3430a38949","unresolved":true,"context_lines":[{"line_number":88,"context_line":"   on the backend DNS servers if the pool has a catalog zone configured."},{"line_number":89,"context_line":""},{"line_number":90,"context_line":""},{"line_number":91,"context_line":"Storage Changes"},{"line_number":92,"context_line":"---------------"},{"line_number":93,"context_line":""},{"line_number":94,"context_line":"1. The zone database schema will need to be updated to add a new \"type\" of"}],"source_content_type":"text/x-rst","patch_set":8,"id":"dcafd166_c72fc3c6","line":91,"in_reply_to":"c800dc70_4fdd767b","updated":"2023-01-20 19:32:49.000000000","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","commit_id":"bbc663b4fbb35e0c9cade9d50c0f0b1133ecee38"},{"author":{"_account_id":32755,"name":"Christian Rohmann","email":"christian.rohmann@inovex.de","username":"frittentheke"},"change_message_id":"a49117131810c2040f77973c78e957b22ed7732e","unresolved":false,"context_lines":[{"line_number":88,"context_line":"   on the backend DNS servers if the pool has a catalog zone configured."},{"line_number":89,"context_line":""},{"line_number":90,"context_line":""},{"line_number":91,"context_line":"Storage Changes"},{"line_number":92,"context_line":"---------------"},{"line_number":93,"context_line":""},{"line_number":94,"context_line":"1. The zone database schema will need to be updated to add a new \"type\" of"}],"source_content_type":"text/x-rst","patch_set":8,"id":"fd987fa9_da1a9e77","line":91,"in_reply_to":"d301ef75_63a5c6d0","updated":"2023-01-19 07:30:45.000000000","message":"Ack","commit_id":"bbc663b4fbb35e0c9cade9d50c0f0b1133ecee38"},{"author":{"_account_id":11628,"name":"Michael Johnson","email":"johnsomor@gmail.com","username":"johnsom"},"change_message_id":"4ce2d32eacc84cdb3defe55294a877c0d78c84bc","unresolved":true,"context_lines":[{"line_number":88,"context_line":"   on the backend DNS servers if the pool has a catalog zone configured."},{"line_number":89,"context_line":""},{"line_number":90,"context_line":""},{"line_number":91,"context_line":"Storage Changes"},{"line_number":92,"context_line":"---------------"},{"line_number":93,"context_line":""},{"line_number":94,"context_line":"1. The zone database schema will need to be updated to add a new \"type\" of"}],"source_content_type":"text/x-rst","patch_set":8,"id":"e8e11d57_8dff271a","line":91,"in_reply_to":"dcafd166_c72fc3c6","updated":"2023-01-20 21:58:59.000000000","message":"Ah, d) is already discussed in the \"Central Changes\" section, item #2.","commit_id":"bbc663b4fbb35e0c9cade9d50c0f0b1133ecee38"},{"author":{"_account_id":32755,"name":"Christian Rohmann","email":"christian.rohmann@inovex.de","username":"frittentheke"},"change_message_id":"2fa0bba9a759238f155fb2dc0af45728fea29551","unresolved":false,"context_lines":[{"line_number":88,"context_line":"   on the backend DNS servers if the pool has a catalog zone configured."},{"line_number":89,"context_line":""},{"line_number":90,"context_line":""},{"line_number":91,"context_line":"Storage Changes"},{"line_number":92,"context_line":"---------------"},{"line_number":93,"context_line":""},{"line_number":94,"context_line":"1. The zone database schema will need to be updated to add a new \"type\" of"}],"source_content_type":"text/x-rst","patch_set":8,"id":"68fa2aef_d8a27ab4","line":91,"in_reply_to":"e8e11d57_8dff271a","updated":"2023-01-24 20:49:51.000000000","message":"Ack","commit_id":"bbc663b4fbb35e0c9cade9d50c0f0b1133ecee38"},{"author":{"_account_id":32755,"name":"Christian Rohmann","email":"christian.rohmann@inovex.de","username":"frittentheke"},"change_message_id":"79a22c12731126427d0e5469c3b832d450e45c0c","unresolved":true,"context_lines":[{"line_number":88,"context_line":"   on the backend DNS servers if the pool has a catalog zone configured."},{"line_number":89,"context_line":""},{"line_number":90,"context_line":""},{"line_number":91,"context_line":"Storage Changes"},{"line_number":92,"context_line":"---------------"},{"line_number":93,"context_line":""},{"line_number":94,"context_line":"1. The zone database schema will need to be updated to add a new \"type\" of"}],"source_content_type":"text/x-rst","patch_set":8,"id":"c800dc70_4fdd767b","line":91,"in_reply_to":"fd987fa9_da1a9e77","updated":"2023-01-20 09:14:51.000000000","message":"Sorry Michael, I did not mean to just reply with Ack ... responding to you by section:\n\na) I am convinced having the catalog being a zone in the database seems to make sense. So you are proposing to just use the established mechanisms for injecting and updating https://docs.openstack.org/designate/latest/admin/multiple-pools.html#pools-configuration for all required workflows to update any of the settings then?\n\nWill you be updating the storage section of the draft accordingly?\n\n\nb) My argument was rather to allow for multiple schemas to be supported at the same time, which would then require this to be configurable and per-pool. But maybe that is overkill to anticipate people to run different schemas among their pools and secondaries. But maybe a global config setting (which can always be added to Designate later) to allow sectting the schema version the renderer produces makes sense?\n\nc) -\n\nd) Good points. We also ran into issues with inconsistent serial numbers due to the time being used. The change towards a batch mode (https://review.opendev.org/c/openstack/designate/+/823325) looks promising. There is a long standing change to do increments instead of using the timestamp (https://review.opendev.org/c/openstack/designate/+/776173), maybe that is obsolete then? In any case the current zone serial code seems racy. Even a single Designate instance already requires coordination, see https://review.opendev.org/c/openstack/designate/+/776173/comments/29f20aba_7e006d1e, to coordinate the workers or whatever.\n\nBack to catalog zones though: How would the serial of the catalog update then? With the new batch mechanism, could the producer receive some code to increment the catalog zone serial on every relevant action: creation and deletion of zones?","commit_id":"bbc663b4fbb35e0c9cade9d50c0f0b1133ecee38"}],"specs/zed/catalog-zones.rst":[{"author":{"_account_id":13252,"name":"Dr. Jens Harbott","display_name":"Jens Harbott (frickler)","email":"frickler@offenerstapel.de","username":"jrosenboom"},"change_message_id":"20716b76d3d2b7d5f31f10ddb40fe9370c99d75b","unresolved":true,"context_lines":[{"line_number":44,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":45,"context_line":"Support for providing `catalog zones` should be added to Designate."},{"line_number":46,"context_line":""},{"line_number":47,"context_line":"In essence `catalog zones` provide easy provisioning capabilities of lists of zones on secondary servers"},{"line_number":48,"context_line":"via AXFR from a special zone, the `catalog`."},{"line_number":49,"context_line":""},{"line_number":50,"context_line":"The below links explain the catalog zone feature, use cases and data model:"}],"source_content_type":"text/x-rst","patch_set":1,"id":"64fd512b_13d0e8e4","line":47,"updated":"2022-07-11 09:07:18.000000000","message":"Nit: Please keep lines wrapped to a maximum of 80 chars, better 72, makes for easier reading and editing.","commit_id":"18d3f53fa4c4787cf15f0bf08d32fe8882135cdc"},{"author":{"_account_id":32755,"name":"Christian Rohmann","email":"christian.rohmann@inovex.de","username":"frittentheke"},"change_message_id":"bab52ac87a722751ed5155097cfd304d525232da","unresolved":true,"context_lines":[{"line_number":44,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":45,"context_line":"Support for providing `catalog zones` should be added to Designate."},{"line_number":46,"context_line":""},{"line_number":47,"context_line":"In essence `catalog zones` provide easy provisioning capabilities of lists of zones on secondary servers"},{"line_number":48,"context_line":"via AXFR from a special zone, the `catalog`."},{"line_number":49,"context_line":""},{"line_number":50,"context_line":"The below links explain the catalog zone feature, use cases and data model:"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1d8022bb_53d472e3","line":47,"in_reply_to":"64fd512b_13d0e8e4","updated":"2022-07-11 12:51:15.000000000","message":"hopefully fixed with new patchset.","commit_id":"18d3f53fa4c4787cf15f0bf08d32fe8882135cdc"},{"author":{"_account_id":13252,"name":"Dr. Jens Harbott","display_name":"Jens Harbott (frickler)","email":"frickler@offenerstapel.de","username":"jrosenboom"},"change_message_id":"20716b76d3d2b7d5f31f10ddb40fe9370c99d75b","unresolved":true,"context_lines":[{"line_number":72,"context_line":"mDNS shall receive the capability to provide a catalog zone following the proposed RFC"},{"line_number":73,"context_line":"as part of the AXFR handling from secondary servers:"},{"line_number":74,"context_line":""},{"line_number":75,"context_line":"* https://opendev.org/openstack/designate/src/branch/master/designate/mdns/handler.py"},{"line_number":76,"context_line":""},{"line_number":77,"context_line":""},{"line_number":78,"context_line":"Potentially some options the likes of an option to enable this feature per server pool"}],"source_content_type":"text/x-rst","patch_set":1,"id":"306b3809_a8162208","line":75,"updated":"2022-07-11 09:07:18.000000000","message":"From the refs given, I\u0027m not sure that any change is needed at all, because the zone should look like any other zone to Designate, or am I missing something? So this needs to include more detail about what actually should change.","commit_id":"18d3f53fa4c4787cf15f0bf08d32fe8882135cdc"},{"author":{"_account_id":32755,"name":"Christian Rohmann","email":"christian.rohmann@inovex.de","username":"frittentheke"},"change_message_id":"bd08ab9b691e055663c645a37281ed790889d65b","unresolved":false,"context_lines":[{"line_number":72,"context_line":"mDNS shall receive the capability to provide a catalog zone following the proposed RFC"},{"line_number":73,"context_line":"as part of the AXFR handling from secondary servers:"},{"line_number":74,"context_line":""},{"line_number":75,"context_line":"* https://opendev.org/openstack/designate/src/branch/master/designate/mdns/handler.py"},{"line_number":76,"context_line":""},{"line_number":77,"context_line":""},{"line_number":78,"context_line":"Potentially some options the likes of an option to enable this feature per server pool"}],"source_content_type":"text/x-rst","patch_set":1,"id":"bad37ddc_92f02bfc","line":75,"in_reply_to":"20e006fe_06165039","updated":"2022-08-25 12:48:22.000000000","message":"Ack","commit_id":"18d3f53fa4c4787cf15f0bf08d32fe8882135cdc"},{"author":{"_account_id":32755,"name":"Christian Rohmann","email":"christian.rohmann@inovex.de","username":"frittentheke"},"change_message_id":"bab52ac87a722751ed5155097cfd304d525232da","unresolved":true,"context_lines":[{"line_number":72,"context_line":"mDNS shall receive the capability to provide a catalog zone following the proposed RFC"},{"line_number":73,"context_line":"as part of the AXFR handling from secondary servers:"},{"line_number":74,"context_line":""},{"line_number":75,"context_line":"* https://opendev.org/openstack/designate/src/branch/master/designate/mdns/handler.py"},{"line_number":76,"context_line":""},{"line_number":77,"context_line":""},{"line_number":78,"context_line":"Potentially some options the likes of an option to enable this feature per server pool"}],"source_content_type":"text/x-rst","patch_set":1,"id":"db3a2834_b4a1eb06","line":75,"in_reply_to":"306b3809_a8162208","updated":"2022-07-11 12:51:15.000000000","message":"I believe we misunderstood. \n\nI propose for Designate to be able to PROVIDE a catalog zone with all of the zones to allow efficient provisioning of secondaries / backends in the configured pools such as BIND9 via AXFR - not about providing this as a \"feature\" to users or their zones.\n\nCatalog zones completely remove the requirement to actively add zones with those implementations that support consuming them in order to know the zones they shall serve.\n\nAt least from a quick look at the source, would require some additional logic in the handler (https://opendev.org/openstack/designate/src/commit/d05232fc075ffe6bfaf7a537334fe081bb41a65c/designate/mdns/handler.py#L201) to render this type of zone.","commit_id":"18d3f53fa4c4787cf15f0bf08d32fe8882135cdc"},{"author":{"_account_id":11628,"name":"Michael Johnson","email":"johnsomor@gmail.com","username":"johnsom"},"change_message_id":"c817c9f59d18e2be850be2aba8b4f376574cff08","unresolved":true,"context_lines":[{"line_number":72,"context_line":"mDNS shall receive the capability to provide a catalog zone following the proposed RFC"},{"line_number":73,"context_line":"as part of the AXFR handling from secondary servers:"},{"line_number":74,"context_line":""},{"line_number":75,"context_line":"* https://opendev.org/openstack/designate/src/branch/master/designate/mdns/handler.py"},{"line_number":76,"context_line":""},{"line_number":77,"context_line":""},{"line_number":78,"context_line":"Potentially some options the likes of an option to enable this feature per server pool"}],"source_content_type":"text/x-rst","patch_set":1,"id":"20e006fe_06165039","line":75,"in_reply_to":"db3a2834_b4a1eb06","updated":"2022-08-10 21:00:51.000000000","message":"Yeah, this is quite considerate change to the miniDNS. It will have to know how to create/render the catalog zones based on the list of created zones.","commit_id":"18d3f53fa4c4787cf15f0bf08d32fe8882135cdc"},{"author":{"_account_id":13252,"name":"Dr. Jens Harbott","display_name":"Jens Harbott (frickler)","email":"frickler@offenerstapel.de","username":"jrosenboom"},"change_message_id":"20716b76d3d2b7d5f31f10ddb40fe9370c99d75b","unresolved":true,"context_lines":[{"line_number":80,"context_line":""},{"line_number":81,"context_line":"* https://docs.openstack.org/designate/latest/admin/pools.html"},{"line_number":82,"context_line":""},{"line_number":83,"context_line":""},{"line_number":84,"context_line":""},{"line_number":85,"context_line":"Assignee(s)"},{"line_number":86,"context_line":"-----------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"b99ba0fa_1e096d55","line":83,"updated":"2022-07-11 09:07:18.000000000","message":"Seems you dropped the \"Alternatives\" section. You should explain why it is not a valid option to handle this in the nameserver setup outside of Designate.","commit_id":"18d3f53fa4c4787cf15f0bf08d32fe8882135cdc"},{"author":{"_account_id":32755,"name":"Christian Rohmann","email":"christian.rohmann@inovex.de","username":"frittentheke"},"change_message_id":"bab52ac87a722751ed5155097cfd304d525232da","unresolved":true,"context_lines":[{"line_number":80,"context_line":""},{"line_number":81,"context_line":"* https://docs.openstack.org/designate/latest/admin/pools.html"},{"line_number":82,"context_line":""},{"line_number":83,"context_line":""},{"line_number":84,"context_line":""},{"line_number":85,"context_line":"Assignee(s)"},{"line_number":86,"context_line":"-----------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"f3ffbb94_b70722d4","line":83,"in_reply_to":"b99ba0fa_1e096d55","updated":"2022-07-11 12:51:15.000000000","message":"From an architecture point of view Designate is the primary / master for the DNS zones as the data (zones and records) is created here. All I am proposing is to provide the list of all zones via a catalog zone / in a certain format.\n\nAnd yes the secondary servers would then simply needs a few lines of config to make use of this and there would be no active zone \"add\" and \"delete\" required anymore.\n\nThere really is no alternative. You either provide a the list of zones in the documented and supported catalog zone format or not. Being able to fetch the list of zones via the API already and then creating such a zone externally from Designate solely beats the purpose.","commit_id":"18d3f53fa4c4787cf15f0bf08d32fe8882135cdc"},{"author":{"_account_id":13252,"name":"Dr. Jens Harbott","display_name":"Jens Harbott (frickler)","email":"frickler@offenerstapel.de","username":"jrosenboom"},"change_message_id":"20716b76d3d2b7d5f31f10ddb40fe9370c99d75b","unresolved":true,"context_lines":[{"line_number":84,"context_line":""},{"line_number":85,"context_line":"Assignee(s)"},{"line_number":86,"context_line":"-----------"},{"line_number":87,"context_line":"-"}],"source_content_type":"text/x-rst","patch_set":1,"id":"576ecbc1_fd3e69e2","line":87,"updated":"2022-07-11 09:07:18.000000000","message":"Would you also intend to supply the implementation for this spec? Without an assignee this spec will just collect dust.","commit_id":"18d3f53fa4c4787cf15f0bf08d32fe8882135cdc"},{"author":{"_account_id":32755,"name":"Christian Rohmann","email":"christian.rohmann@inovex.de","username":"frittentheke"},"change_message_id":"bab52ac87a722751ed5155097cfd304d525232da","unresolved":true,"context_lines":[{"line_number":84,"context_line":""},{"line_number":85,"context_line":"Assignee(s)"},{"line_number":86,"context_line":"-----------"},{"line_number":87,"context_line":"-"}],"source_content_type":"text/x-rst","patch_set":1,"id":"d3fffb38_f039a7dc","line":87,"in_reply_to":"576ecbc1_fd3e69e2","updated":"2022-07-11 12:51:15.000000000","message":"Yes.","commit_id":"18d3f53fa4c4787cf15f0bf08d32fe8882135cdc"},{"author":{"_account_id":11628,"name":"Michael Johnson","email":"johnsomor@gmail.com","username":"johnsom"},"change_message_id":"97b457ae6a193a9771f792d0538f0edd06fe7840","unresolved":true,"context_lines":[{"line_number":16,"context_line":" Catalog Zones"},{"line_number":17,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":18,"context_line":""},{"line_number":19,"context_line":"https://blueprints.launchpad.net/designate/+spec/catalog-zones"},{"line_number":20,"context_line":""},{"line_number":21,"context_line":""},{"line_number":22,"context_line":" DNS Catalog Zones is a method in which a catalog of zones is"}],"source_content_type":"text/x-rst","patch_set":2,"id":"48f5325c_4885db00","line":19,"updated":"2022-07-13 21:13:15.000000000","message":"FYI, OpenStack in general has moved away from doing blueprint tracking and has focused more on specs for new features.\nSo, you don\u0027t need to worry too much about updating the blueprint. Hopefully that will save you some time/work.\nI probably need to update the spec template boilerplate in this repo.\n\nThe critical part is getting a detailed spec that everyone agrees on.","commit_id":"c45bdd4716468b0497afc86079ccc19bdf4f03ea"},{"author":{"_account_id":32755,"name":"Christian Rohmann","email":"christian.rohmann@inovex.de","username":"frittentheke"},"change_message_id":"7e97dcd7f1ac3610a3bc1877c472216c98294a4a","unresolved":false,"context_lines":[{"line_number":16,"context_line":" Catalog Zones"},{"line_number":17,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":18,"context_line":""},{"line_number":19,"context_line":"https://blueprints.launchpad.net/designate/+spec/catalog-zones"},{"line_number":20,"context_line":""},{"line_number":21,"context_line":""},{"line_number":22,"context_line":" DNS Catalog Zones is a method in which a catalog of zones is"}],"source_content_type":"text/x-rst","patch_set":2,"id":"00af37a5_1d7536b7","line":19,"in_reply_to":"48f5325c_4885db00","updated":"2022-07-14 11:52:21.000000000","message":"Done. I used a mixture of the last spec and the template and went \"with the flow\".\nI will add all sections of the current template. Sorry about the confusion, but I never intended to leave any important sections out of the spec.","commit_id":"c45bdd4716468b0497afc86079ccc19bdf4f03ea"},{"author":{"_account_id":11628,"name":"Michael Johnson","email":"johnsomor@gmail.com","username":"johnsom"},"change_message_id":"97b457ae6a193a9771f792d0538f0edd06fe7840","unresolved":true,"context_lines":[{"line_number":38,"context_line":"manually creates, modifies and deleted every zone one by one via a"},{"line_number":39,"context_line":"call to a management tooling like BIND\u0027s `rndc`. This mechanism has"},{"line_number":40,"context_line":"scaling issues for large number of domains being added and maintained"},{"line_number":41,"context_line":"on secondary server and a slow convergence in case of new servers being"},{"line_number":42,"context_line":"added to the server pool."},{"line_number":43,"context_line":""},{"line_number":44,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"24c3742e_575df845","line":41,"range":{"start_line":41,"start_character":26,"end_line":41,"end_character":42},"updated":"2022-07-13 21:13:15.000000000","message":"Depending on the TTL of the catalog zones, the proactive approach Designate uses today may be faster.","commit_id":"c45bdd4716468b0497afc86079ccc19bdf4f03ea"},{"author":{"_account_id":32755,"name":"Christian Rohmann","email":"christian.rohmann@inovex.de","username":"frittentheke"},"change_message_id":"7e97dcd7f1ac3610a3bc1877c472216c98294a4a","unresolved":true,"context_lines":[{"line_number":38,"context_line":"manually creates, modifies and deleted every zone one by one via a"},{"line_number":39,"context_line":"call to a management tooling like BIND\u0027s `rndc`. This mechanism has"},{"line_number":40,"context_line":"scaling issues for large number of domains being added and maintained"},{"line_number":41,"context_line":"on secondary server and a slow convergence in case of new servers being"},{"line_number":42,"context_line":"added to the server pool."},{"line_number":43,"context_line":""},{"line_number":44,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"e8571e1f_245eb52b","line":41,"range":{"start_line":41,"start_character":26,"end_line":41,"end_character":42},"in_reply_to":"24c3742e_575df845","updated":"2022-07-14 11:52:21.000000000","message":"Isn\u0027t \"fast propagation\" exactly what the NOTIFY mechanism / message (https://datatracker.ietf.org/doc/html/rfc1996) is all about? Letting secondaries know they should update their zone data? In the case of catalog zones the master only needs to notify the secondaries about that single zone, secondaries can then AXFR whatever they require.\n\nAs a fallback an additional safety net the catalog zone should obviously have a lower REFRESH time in its SOA than the default of 3600 seconds (24 hrs) - see my remarks on additional config parameters to the pools, this should be one of them, defaulting to a sensible value.","commit_id":"c45bdd4716468b0497afc86079ccc19bdf4f03ea"},{"author":{"_account_id":11628,"name":"Michael Johnson","email":"johnsomor@gmail.com","username":"johnsom"},"change_message_id":"97b457ae6a193a9771f792d0538f0edd06fe7840","unresolved":true,"context_lines":[{"line_number":55,"context_line":""},{"line_number":56,"context_line":"* https://zones.cat/"},{"line_number":57,"context_line":"* https://kb.isc.org/docs/aa-01401"},{"line_number":58,"context_line":"* https://datatracker.ietf.org/doc/draft-toorop-dnsop-dns-catalog-zones/"},{"line_number":59,"context_line":""},{"line_number":60,"context_line":""},{"line_number":61,"context_line":"There already is support in BIND9, Knot and other major DNS servers like"}],"source_content_type":"text/x-rst","patch_set":2,"id":"faf843f6_e0c3cc33","line":58,"updated":"2022-07-13 21:13:15.000000000","message":"Can we update this with the current document, the one linked is deprecated.\n\nhttps://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-catalog-zones/","commit_id":"c45bdd4716468b0497afc86079ccc19bdf4f03ea"},{"author":{"_account_id":32755,"name":"Christian Rohmann","email":"christian.rohmann@inovex.de","username":"frittentheke"},"change_message_id":"7e97dcd7f1ac3610a3bc1877c472216c98294a4a","unresolved":false,"context_lines":[{"line_number":55,"context_line":""},{"line_number":56,"context_line":"* https://zones.cat/"},{"line_number":57,"context_line":"* https://kb.isc.org/docs/aa-01401"},{"line_number":58,"context_line":"* https://datatracker.ietf.org/doc/draft-toorop-dnsop-dns-catalog-zones/"},{"line_number":59,"context_line":""},{"line_number":60,"context_line":""},{"line_number":61,"context_line":"There already is support in BIND9, Knot and other major DNS servers like"}],"source_content_type":"text/x-rst","patch_set":2,"id":"596b7a68_d49312cf","line":58,"in_reply_to":"faf843f6_e0c3cc33","updated":"2022-07-14 11:52:21.000000000","message":"Ack","commit_id":"c45bdd4716468b0497afc86079ccc19bdf4f03ea"},{"author":{"_account_id":11628,"name":"Michael Johnson","email":"johnsomor@gmail.com","username":"johnsom"},"change_message_id":"97b457ae6a193a9771f792d0538f0edd06fe7840","unresolved":true,"context_lines":[{"line_number":56,"context_line":"* https://zones.cat/"},{"line_number":57,"context_line":"* https://kb.isc.org/docs/aa-01401"},{"line_number":58,"context_line":"* https://datatracker.ietf.org/doc/draft-toorop-dnsop-dns-catalog-zones/"},{"line_number":59,"context_line":""},{"line_number":60,"context_line":""},{"line_number":61,"context_line":"There already is support in BIND9, Knot and other major DNS servers like"},{"line_number":62,"context_line":"PowerDNS or NSD to consume `catalog zones`, all of them are backends"}],"source_content_type":"text/x-rst","patch_set":2,"id":"30393040_5ffe148f","line":59,"updated":"2022-07-13 21:13:15.000000000","message":"It\u0027s a bit risky to implement against an ID as opposed to an RFC. At the ID phase it is more likely that structure and functionality can change.\nI think the fact that a number of our backends already support it is a good sign.","commit_id":"c45bdd4716468b0497afc86079ccc19bdf4f03ea"},{"author":{"_account_id":32755,"name":"Christian Rohmann","email":"christian.rohmann@inovex.de","username":"frittentheke"},"change_message_id":"7e97dcd7f1ac3610a3bc1877c472216c98294a4a","unresolved":false,"context_lines":[{"line_number":56,"context_line":"* https://zones.cat/"},{"line_number":57,"context_line":"* https://kb.isc.org/docs/aa-01401"},{"line_number":58,"context_line":"* https://datatracker.ietf.org/doc/draft-toorop-dnsop-dns-catalog-zones/"},{"line_number":59,"context_line":""},{"line_number":60,"context_line":""},{"line_number":61,"context_line":"There already is support in BIND9, Knot and other major DNS servers like"},{"line_number":62,"context_line":"PowerDNS or NSD to consume `catalog zones`, all of them are backends"}],"source_content_type":"text/x-rst","patch_set":2,"id":"75bb7571_0a42f8e2","line":59,"in_reply_to":"30393040_5ffe148f","updated":"2022-07-14 11:52:21.000000000","message":"Ack","commit_id":"c45bdd4716468b0497afc86079ccc19bdf4f03ea"},{"author":{"_account_id":11628,"name":"Michael Johnson","email":"johnsomor@gmail.com","username":"johnsom"},"change_message_id":"97b457ae6a193a9771f792d0538f0edd06fe7840","unresolved":true,"context_lines":[{"line_number":67,"context_line":"* NSD https://github.com/IETF-Hackathon/NSDCatZ"},{"line_number":68,"context_line":"* PowerDNS https://github.com/PowerDNS/powercatz/"},{"line_number":69,"context_line":""},{"line_number":70,"context_line":"Apart from improving on performance and resilience of the provisioning"},{"line_number":71,"context_line":"in general, supporting `catalog zones` also enables Designate to support"},{"line_number":72,"context_line":"other backend implementationsas secondary DNS servers without the"},{"line_number":73,"context_line":"requirement for dedicated drivers."}],"source_content_type":"text/x-rst","patch_set":2,"id":"a497d115_0df04efe","line":70,"range":{"start_line":70,"start_character":24,"end_line":70,"end_character":35},"updated":"2022-07-13 21:13:15.000000000","message":"Same comment here, I think there are situations where the proactive approach may be faster.","commit_id":"c45bdd4716468b0497afc86079ccc19bdf4f03ea"},{"author":{"_account_id":32755,"name":"Christian Rohmann","email":"christian.rohmann@inovex.de","username":"frittentheke"},"change_message_id":"7e97dcd7f1ac3610a3bc1877c472216c98294a4a","unresolved":true,"context_lines":[{"line_number":67,"context_line":"* NSD https://github.com/IETF-Hackathon/NSDCatZ"},{"line_number":68,"context_line":"* PowerDNS https://github.com/PowerDNS/powercatz/"},{"line_number":69,"context_line":""},{"line_number":70,"context_line":"Apart from improving on performance and resilience of the provisioning"},{"line_number":71,"context_line":"in general, supporting `catalog zones` also enables Designate to support"},{"line_number":72,"context_line":"other backend implementationsas secondary DNS servers without the"},{"line_number":73,"context_line":"requirement for dedicated drivers."}],"source_content_type":"text/x-rst","patch_set":2,"id":"b8d6dd6e_6ab31a3d","line":70,"range":{"start_line":70,"start_character":24,"end_line":70,"end_character":35},"in_reply_to":"a497d115_0df04efe","updated":"2022-07-14 11:52:21.000000000","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.","commit_id":"c45bdd4716468b0497afc86079ccc19bdf4f03ea"},{"author":{"_account_id":11628,"name":"Michael Johnson","email":"johnsomor@gmail.com","username":"johnsom"},"change_message_id":"c817c9f59d18e2be850be2aba8b4f376574cff08","unresolved":true,"context_lines":[{"line_number":67,"context_line":"* NSD https://github.com/IETF-Hackathon/NSDCatZ"},{"line_number":68,"context_line":"* PowerDNS https://github.com/PowerDNS/powercatz/"},{"line_number":69,"context_line":""},{"line_number":70,"context_line":"Apart from improving on performance and resilience of the provisioning"},{"line_number":71,"context_line":"in general, supporting `catalog zones` also enables Designate to support"},{"line_number":72,"context_line":"other backend implementationsas secondary DNS servers without the"},{"line_number":73,"context_line":"requirement for dedicated drivers."}],"source_content_type":"text/x-rst","patch_set":2,"id":"d7a6e54f_32cba7a3","line":70,"range":{"start_line":70,"start_character":24,"end_line":70,"end_character":35},"in_reply_to":"b8d6dd6e_6ab31a3d","updated":"2022-08-10 21:00:51.000000000","message":"Actually, just one \"designate-manage pool update\" will update all of the zones, so it does not need to be called for every zone.","commit_id":"c45bdd4716468b0497afc86079ccc19bdf4f03ea"},{"author":{"_account_id":32755,"name":"Christian Rohmann","email":"christian.rohmann@inovex.de","username":"frittentheke"},"change_message_id":"bd08ab9b691e055663c645a37281ed790889d65b","unresolved":true,"context_lines":[{"line_number":67,"context_line":"* NSD https://github.com/IETF-Hackathon/NSDCatZ"},{"line_number":68,"context_line":"* PowerDNS https://github.com/PowerDNS/powercatz/"},{"line_number":69,"context_line":""},{"line_number":70,"context_line":"Apart from improving on performance and resilience of the provisioning"},{"line_number":71,"context_line":"in general, supporting `catalog zones` also enables Designate to support"},{"line_number":72,"context_line":"other backend implementationsas secondary DNS servers without the"},{"line_number":73,"context_line":"requirement for dedicated drivers."}],"source_content_type":"text/x-rst","patch_set":2,"id":"9282960d_9814f443","line":70,"range":{"start_line":70,"start_character":24,"end_line":70,"end_character":35},"in_reply_to":"d7a6e54f_32cba7a3","updated":"2022-08-25 12:48:22.000000000","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.","commit_id":"c45bdd4716468b0497afc86079ccc19bdf4f03ea"},{"author":{"_account_id":11628,"name":"Michael Johnson","email":"johnsomor@gmail.com","username":"johnsom"},"change_message_id":"97b457ae6a193a9771f792d0538f0edd06fe7840","unresolved":true,"context_lines":[{"line_number":70,"context_line":"Apart from improving on performance and resilience of the provisioning"},{"line_number":71,"context_line":"in general, supporting `catalog zones` also enables Designate to support"},{"line_number":72,"context_line":"other backend implementationsas secondary DNS servers without the"},{"line_number":73,"context_line":"requirement for dedicated drivers."},{"line_number":74,"context_line":""},{"line_number":75,"context_line":""},{"line_number":76,"context_line":"Central Changes"}],"source_content_type":"text/x-rst","patch_set":2,"id":"643b30c1_1bc90e35","line":73,"updated":"2022-07-13 21:13:15.000000000","message":"Wouldn\u0027t Designate still need to setup the catalog zone on the secondaries to set it up to start syncing? This would still require a dedicated driver for the backend.\nThe other concern is each zone will need a TSIG key loaded on the secondary, prior to establishing the catalog zone. This is needed to make sure the zone transfers are authentic. Per the ID, only the key identifier can (and should) be published in the catalog, so those keys will still need to be pre-loaded.","commit_id":"c45bdd4716468b0497afc86079ccc19bdf4f03ea"},{"author":{"_account_id":32755,"name":"Christian Rohmann","email":"christian.rohmann@inovex.de","username":"frittentheke"},"change_message_id":"7e97dcd7f1ac3610a3bc1877c472216c98294a4a","unresolved":true,"context_lines":[{"line_number":70,"context_line":"Apart from improving on performance and resilience of the provisioning"},{"line_number":71,"context_line":"in general, supporting `catalog zones` also enables Designate to support"},{"line_number":72,"context_line":"other backend implementationsas secondary DNS servers without the"},{"line_number":73,"context_line":"requirement for dedicated drivers."},{"line_number":74,"context_line":""},{"line_number":75,"context_line":""},{"line_number":76,"context_line":"Central Changes"}],"source_content_type":"text/x-rst","patch_set":2,"id":"006fb99c_f4c70aac","line":73,"in_reply_to":"643b30c1_1bc90e35","updated":"2022-07-14 11:52:21.000000000","message":"Good point. Quite honestly Designate could just leave this to the operator to configure in their secondaries config. Catalog zones offer such a big chance to make the whole management of secondaries so much more lightweight to Designate.\n\nThere certainly could be some config snippet to explain what needs to be configured like here for BIND9 and the auth to use RNDC: https://docs.openstack.org/designate/latest/admin/backends/bind9.html\n\nBut with catalog zones hopefully being a standardized approach, this should not be anything Designate needs to actively care about, adding must more code to maintain.","commit_id":"c45bdd4716468b0497afc86079ccc19bdf4f03ea"},{"author":{"_account_id":11628,"name":"Michael Johnson","email":"johnsomor@gmail.com","username":"johnsom"},"change_message_id":"97b457ae6a193a9771f792d0538f0edd06fe7840","unresolved":true,"context_lines":[{"line_number":71,"context_line":"in general, supporting `catalog zones` also enables Designate to support"},{"line_number":72,"context_line":"other backend implementationsas secondary DNS servers without the"},{"line_number":73,"context_line":"requirement for dedicated drivers."},{"line_number":74,"context_line":""},{"line_number":75,"context_line":""},{"line_number":76,"context_line":"Central Changes"},{"line_number":77,"context_line":"---------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"52e40fd8_e793c667","line":74,"updated":"2022-07-13 21:13:15.000000000","message":"We should discuss here if we see a need for the Change of Ownership (coo) property in the Designate implementation.\nI\u0027m not sure I see an immediate need.","commit_id":"c45bdd4716468b0497afc86079ccc19bdf4f03ea"},{"author":{"_account_id":32755,"name":"Christian Rohmann","email":"christian.rohmann@inovex.de","username":"frittentheke"},"change_message_id":"e9f83a9ea3a32e0308f729b614fb8c592a8894e4","unresolved":true,"context_lines":[{"line_number":71,"context_line":"in general, supporting `catalog zones` also enables Designate to support"},{"line_number":72,"context_line":"other backend implementationsas secondary DNS servers without the"},{"line_number":73,"context_line":"requirement for dedicated drivers."},{"line_number":74,"context_line":""},{"line_number":75,"context_line":""},{"line_number":76,"context_line":"Central Changes"},{"line_number":77,"context_line":"---------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3733f556_a94d0254","line":74,"in_reply_to":"49be9034_5cf639d9","updated":"2022-08-31 09:29:07.000000000","message":"No doubt this is still a moving target, but in my impression moving quickly towards a first RFC and therefore I want for Designate and my little farm of BIND9 secondaries to be part of it.\n\n\nAs for the COO (https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-dns-catalog-zones#section-4.4.1), I believe this mostly affects Designate when using multiple server pools:\n\n\u003e   The coo property facilitates controlled migration of a member zone\n\u003e   from one catalog to another.\n\nI am trying to understand what the initial cause of such a \"change\" is? A transfer of the domain ownership to another entity? Do you see this being used in case of zone transfers between projects (via https://docs.openstack.org/api-ref/dns/#create-zone-transfer-request)?","commit_id":"c45bdd4716468b0497afc86079ccc19bdf4f03ea"},{"author":{"_account_id":32755,"name":"Christian Rohmann","email":"christian.rohmann@inovex.de","username":"frittentheke"},"change_message_id":"7e97dcd7f1ac3610a3bc1877c472216c98294a4a","unresolved":true,"context_lines":[{"line_number":71,"context_line":"in general, supporting `catalog zones` also enables Designate to support"},{"line_number":72,"context_line":"other backend implementationsas secondary DNS servers without the"},{"line_number":73,"context_line":"requirement for dedicated drivers."},{"line_number":74,"context_line":""},{"line_number":75,"context_line":""},{"line_number":76,"context_line":"Central Changes"},{"line_number":77,"context_line":"---------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"59381092_9b1fb23d","line":74,"in_reply_to":"52e40fd8_e793c667","updated":"2022-07-14 11:52:21.000000000","message":"Could you elaborate a little more on what you refer to by \"Change of Ownership (coo)\"?","commit_id":"c45bdd4716468b0497afc86079ccc19bdf4f03ea"},{"author":{"_account_id":11628,"name":"Michael Johnson","email":"johnsomor@gmail.com","username":"johnsom"},"change_message_id":"c817c9f59d18e2be850be2aba8b4f376574cff08","unresolved":true,"context_lines":[{"line_number":71,"context_line":"in general, supporting `catalog zones` also enables Designate to support"},{"line_number":72,"context_line":"other backend implementationsas secondary DNS servers without the"},{"line_number":73,"context_line":"requirement for dedicated drivers."},{"line_number":74,"context_line":""},{"line_number":75,"context_line":""},{"line_number":76,"context_line":"Central Changes"},{"line_number":77,"context_line":"---------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"49be9034_5cf639d9","line":74,"in_reply_to":"59381092_9b1fb23d","updated":"2022-08-10 21:00:51.000000000","message":"Page 7 of the Internet Draft (ID) talks about zone Change of Ownership (coo).\nWe should also comment on the implications of Groups (group property) for Designate. I.e. Views/ACLs would likely need this.\nThe serial property was removed in the last draft. The draft is definitely a moving target until this hits the RFC stage.","commit_id":"c45bdd4716468b0497afc86079ccc19bdf4f03ea"},{"author":{"_account_id":11628,"name":"Michael Johnson","email":"johnsomor@gmail.com","username":"johnsom"},"change_message_id":"97b457ae6a193a9771f792d0538f0edd06fe7840","unresolved":true,"context_lines":[{"line_number":83,"context_line":""},{"line_number":84,"context_line":"Potentially some options the likes of an option to enable this feature"},{"line_number":85,"context_line":"per server pool or to set the name of the catalog zone could be added"},{"line_number":86,"context_line":"to pools:"},{"line_number":87,"context_line":""},{"line_number":88,"context_line":"* https://docs.openstack.org/designate/latest/admin/pools.html"},{"line_number":89,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"c78e22b5_7d273db8","line":86,"updated":"2022-07-13 21:13:15.000000000","message":"This sentence is a little hard to follow, but yes, this would have to be setup per-pool so that the right zones end up on the right servers.","commit_id":"c45bdd4716468b0497afc86079ccc19bdf4f03ea"},{"author":{"_account_id":11628,"name":"Michael Johnson","email":"johnsomor@gmail.com","username":"johnsom"},"change_message_id":"97b457ae6a193a9771f792d0538f0edd06fe7840","unresolved":true,"context_lines":[{"line_number":88,"context_line":"* https://docs.openstack.org/designate/latest/admin/pools.html"},{"line_number":89,"context_line":""},{"line_number":90,"context_line":""},{"line_number":91,"context_line":"Alternatives"},{"line_number":92,"context_line":"------------"},{"line_number":93,"context_line":""},{"line_number":94,"context_line":"There is no real alterative to providing a catalog zone."}],"source_content_type":"text/x-rst","patch_set":2,"id":"69371fcb_7a4d382b","line":91,"updated":"2022-07-13 21:13:15.000000000","message":"Please leave in all of the sections of the template so we can comment on those other sections if we see additions. It\u0027s ok to have them just say \"None\", but it gives us an anchor point for comments.\nSpecifically we are missing \"storage\" and \"other\" sections here.","commit_id":"c45bdd4716468b0497afc86079ccc19bdf4f03ea"},{"author":{"_account_id":32755,"name":"Christian Rohmann","email":"christian.rohmann@inovex.de","username":"frittentheke"},"change_message_id":"7e97dcd7f1ac3610a3bc1877c472216c98294a4a","unresolved":false,"context_lines":[{"line_number":88,"context_line":"* https://docs.openstack.org/designate/latest/admin/pools.html"},{"line_number":89,"context_line":""},{"line_number":90,"context_line":""},{"line_number":91,"context_line":"Alternatives"},{"line_number":92,"context_line":"------------"},{"line_number":93,"context_line":""},{"line_number":94,"context_line":"There is no real alterative to providing a catalog zone."}],"source_content_type":"text/x-rst","patch_set":2,"id":"1194a7a7_82222e4f","line":91,"in_reply_to":"69371fcb_7a4d382b","updated":"2022-07-14 11:52:21.000000000","message":"Ack","commit_id":"c45bdd4716468b0497afc86079ccc19bdf4f03ea"},{"author":{"_account_id":11628,"name":"Michael Johnson","email":"johnsomor@gmail.com","username":"johnsom"},"change_message_id":"97b457ae6a193a9771f792d0538f0edd06fe7840","unresolved":true,"context_lines":[{"line_number":89,"context_line":""},{"line_number":90,"context_line":""},{"line_number":91,"context_line":"Alternatives"},{"line_number":92,"context_line":"------------"},{"line_number":93,"context_line":""},{"line_number":94,"context_line":"There is no real alterative to providing a catalog zone."},{"line_number":95,"context_line":"While there is the Designate API available to fetch zone data for other"}],"source_content_type":"text/x-rst","patch_set":2,"id":"5e4e3574_88a83e8d","line":92,"updated":"2022-07-13 21:13:15.000000000","message":"Storage, we will at least need to expand the pools yaml definition to indicate that a pool should have catalog zones configured on them. This would also be an indicator to the worker that individual zone creation would not be required for the pool.","commit_id":"c45bdd4716468b0497afc86079ccc19bdf4f03ea"},{"author":{"_account_id":32755,"name":"Christian Rohmann","email":"christian.rohmann@inovex.de","username":"frittentheke"},"change_message_id":"7e97dcd7f1ac3610a3bc1877c472216c98294a4a","unresolved":false,"context_lines":[{"line_number":89,"context_line":""},{"line_number":90,"context_line":""},{"line_number":91,"context_line":"Alternatives"},{"line_number":92,"context_line":"------------"},{"line_number":93,"context_line":""},{"line_number":94,"context_line":"There is no real alterative to providing a catalog zone."},{"line_number":95,"context_line":"While there is the Designate API available to fetch zone data for other"}],"source_content_type":"text/x-rst","patch_set":2,"id":"eddcdbc4_95a90b36","line":92,"in_reply_to":"5e4e3574_88a83e8d","updated":"2022-07-14 11:52:21.000000000","message":"Ack","commit_id":"c45bdd4716468b0497afc86079ccc19bdf4f03ea"},{"author":{"_account_id":11628,"name":"Michael Johnson","email":"johnsomor@gmail.com","username":"johnsom"},"change_message_id":"97b457ae6a193a9771f792d0538f0edd06fe7840","unresolved":true,"context_lines":[{"line_number":90,"context_line":""},{"line_number":91,"context_line":"Alternatives"},{"line_number":92,"context_line":"------------"},{"line_number":93,"context_line":""},{"line_number":94,"context_line":"There is no real alterative to providing a catalog zone."},{"line_number":95,"context_line":"While there is the Designate API available to fetch zone data for other"},{"line_number":96,"context_line":"means of provisioning backends, the catalog zone provides a common and"}],"source_content_type":"text/x-rst","patch_set":2,"id":"65eba26b_0b1ec7a1","line":93,"updated":"2022-07-13 21:13:15.000000000","message":"Other:\nWe need to describe the security stance for the catalog zone.\nThere are security considerations about having a queriable list of all of the zones hosted in the pool.\nWe need to talk about TSIG configuration for the catalog zones.\nWe need to talk about ACLs such that not everyone can query the catalog zone.","commit_id":"c45bdd4716468b0497afc86079ccc19bdf4f03ea"},{"author":{"_account_id":32755,"name":"Christian Rohmann","email":"christian.rohmann@inovex.de","username":"frittentheke"},"change_message_id":"7e97dcd7f1ac3610a3bc1877c472216c98294a4a","unresolved":true,"context_lines":[{"line_number":90,"context_line":""},{"line_number":91,"context_line":"Alternatives"},{"line_number":92,"context_line":"------------"},{"line_number":93,"context_line":""},{"line_number":94,"context_line":"There is no real alterative to providing a catalog zone."},{"line_number":95,"context_line":"While there is the Designate API available to fetch zone data for other"},{"line_number":96,"context_line":"means of provisioning backends, the catalog zone provides a common and"}],"source_content_type":"text/x-rst","patch_set":2,"id":"e49c48f9_d94ba729","line":93,"in_reply_to":"65eba26b_0b1ec7a1","updated":"2022-07-14 11:52:21.000000000","message":"\u003e Other:\n\u003e We need to describe the security stance for the catalog zone.\n\u003e There are security considerations about having a queriable list of all of the zones hosted in the pool.\n\u003e We need to talk about TSIG configuration for the catalog zones.\n\u003e We need to talk about ACLs such that not everyone can query the catalog zone.\n\nGood points, thanks!\n\nDoing any sort of protection or filtering of catalog zones on source IPs or other arbitrary info to me is out of scope for Designate. https://kb.isc.org/docs/aa-01401 clearly states that production setups should make use of TSIG to protect catalog zones, that totally follows the \"DNS-only\" approach of catalog zones.\n\nSo yes, a configurable value for the TSIG key of a catalog zone is required.","commit_id":"c45bdd4716468b0497afc86079ccc19bdf4f03ea"},{"author":{"_account_id":32755,"name":"Christian Rohmann","email":"christian.rohmann@inovex.de","username":"frittentheke"},"change_message_id":"bd08ab9b691e055663c645a37281ed790889d65b","unresolved":true,"context_lines":[{"line_number":90,"context_line":""},{"line_number":91,"context_line":"Alternatives"},{"line_number":92,"context_line":"------------"},{"line_number":93,"context_line":""},{"line_number":94,"context_line":"There is no real alterative to providing a catalog zone."},{"line_number":95,"context_line":"While there is the Designate API available to fetch zone data for other"},{"line_number":96,"context_line":"means of provisioning backends, the catalog zone provides a common and"}],"source_content_type":"text/x-rst","patch_set":2,"id":"29b8aedb_56d5bf36","line":93,"in_reply_to":"a1ce3042_5e4f04d3","updated":"2022-08-25 12:48:22.000000000","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 ...","commit_id":"c45bdd4716468b0497afc86079ccc19bdf4f03ea"},{"author":{"_account_id":11628,"name":"Michael Johnson","email":"johnsomor@gmail.com","username":"johnsom"},"change_message_id":"c817c9f59d18e2be850be2aba8b4f376574cff08","unresolved":true,"context_lines":[{"line_number":90,"context_line":""},{"line_number":91,"context_line":"Alternatives"},{"line_number":92,"context_line":"------------"},{"line_number":93,"context_line":""},{"line_number":94,"context_line":"There is no real alterative to providing a catalog zone."},{"line_number":95,"context_line":"While there is the Designate API available to fetch zone data for other"},{"line_number":96,"context_line":"means of provisioning backends, the catalog zone provides a common and"}],"source_content_type":"text/x-rst","patch_set":2,"id":"a1ce3042_5e4f04d3","line":93,"in_reply_to":"e49c48f9_d94ba729","updated":"2022-08-10 21:00:51.000000000","message":"So at a minimum the pools configuration would need to be extended to define a \"catalog zone\" TSIG.\nHowever I am still concerned that we are not addressing the ability to restrict queries to the catalog zone.\nThis is called out in the ID:\nIt is RECOMMENDED to limit the systems able to query these zones.\n\nI am not proposing \"non-DNS\" mechanisms as you imply, but using existing means to control access to this catalog data.\n\nI.e. miniDNS would require a valid TSIG to allow the axfr. It could also deny any query to the catalog zone without the TSIG.","commit_id":"c45bdd4716468b0497afc86079ccc19bdf4f03ea"},{"author":{"_account_id":11628,"name":"Michael Johnson","email":"johnsomor@gmail.com","username":"johnsom"},"change_message_id":"97b457ae6a193a9771f792d0538f0edd06fe7840","unresolved":true,"context_lines":[{"line_number":91,"context_line":"Alternatives"},{"line_number":92,"context_line":"------------"},{"line_number":93,"context_line":""},{"line_number":94,"context_line":"There is no real alterative to providing a catalog zone."},{"line_number":95,"context_line":"While there is the Designate API available to fetch zone data for other"},{"line_number":96,"context_line":"means of provisioning backends, the catalog zone provides a common and"},{"line_number":97,"context_line":"agreed interface to provide this data via AXFR and to various DNS"}],"source_content_type":"text/x-rst","patch_set":2,"id":"c1177ce1_cf25885d","line":94,"updated":"2022-07-13 21:13:15.000000000","message":"The alternative is to continue to have the worker process create the zones. Right?","commit_id":"c45bdd4716468b0497afc86079ccc19bdf4f03ea"},{"author":{"_account_id":32755,"name":"Christian Rohmann","email":"christian.rohmann@inovex.de","username":"frittentheke"},"change_message_id":"7e97dcd7f1ac3610a3bc1877c472216c98294a4a","unresolved":true,"context_lines":[{"line_number":91,"context_line":"Alternatives"},{"line_number":92,"context_line":"------------"},{"line_number":93,"context_line":""},{"line_number":94,"context_line":"There is no real alterative to providing a catalog zone."},{"line_number":95,"context_line":"While there is the Designate API available to fetch zone data for other"},{"line_number":96,"context_line":"means of provisioning backends, the catalog zone provides a common and"},{"line_number":97,"context_line":"agreed interface to provide this data via AXFR and to various DNS"}],"source_content_type":"text/x-rst","patch_set":2,"id":"b38d2a22_b20105e1","line":94,"in_reply_to":"c1177ce1_cf25885d","updated":"2022-07-14 11:52:21.000000000","message":"Yes, this was a bit lost in translation. I meant to one either adds this as additional option or not. I shall rephrase this though.","commit_id":"c45bdd4716468b0497afc86079ccc19bdf4f03ea"},{"author":{"_account_id":11628,"name":"Michael Johnson","email":"johnsomor@gmail.com","username":"johnsom"},"change_message_id":"97b457ae6a193a9771f792d0538f0edd06fe7840","unresolved":true,"context_lines":[{"line_number":112,"context_line":"  crohmann"},{"line_number":113,"context_line":""},{"line_number":114,"context_line":""},{"line_number":115,"context_line":"Assignee(s)"},{"line_number":116,"context_line":"-----------"},{"line_number":117,"context_line":"-"}],"source_content_type":"text/x-rst","patch_set":2,"id":"63346878_1345f002","line":115,"updated":"2022-07-13 21:13:15.000000000","message":"This is duplicate, we should go back to the template format that contains the other required sections (work items, upgrade implications, etc.).","commit_id":"c45bdd4716468b0497afc86079ccc19bdf4f03ea"},{"author":{"_account_id":32755,"name":"Christian Rohmann","email":"christian.rohmann@inovex.de","username":"frittentheke"},"change_message_id":"7e97dcd7f1ac3610a3bc1877c472216c98294a4a","unresolved":false,"context_lines":[{"line_number":112,"context_line":"  crohmann"},{"line_number":113,"context_line":""},{"line_number":114,"context_line":""},{"line_number":115,"context_line":"Assignee(s)"},{"line_number":116,"context_line":"-----------"},{"line_number":117,"context_line":"-"}],"source_content_type":"text/x-rst","patch_set":2,"id":"5d41ef9a_ddabe7ce","line":115,"in_reply_to":"63346878_1345f002","updated":"2022-07-14 11:52:21.000000000","message":"Ack","commit_id":"c45bdd4716468b0497afc86079ccc19bdf4f03ea"},{"author":{"_account_id":11628,"name":"Michael Johnson","email":"johnsomor@gmail.com","username":"johnsom"},"change_message_id":"c817c9f59d18e2be850be2aba8b4f376574cff08","unresolved":true,"context_lines":[{"line_number":74,"context_line":"-----------"},{"line_number":75,"context_line":""},{"line_number":76,"context_line":""},{"line_number":77,"context_line":"Central Changes"},{"line_number":78,"context_line":"---------------"},{"line_number":79,"context_line":"mDNS shall receive the capability to provide a catalog zone following"},{"line_number":80,"context_line":"the proposed RFC as part of the AXFR handling from secondary servers:"}],"source_content_type":"text/x-rst","patch_set":3,"id":"1e95f536_3801ca59","line":77,"updated":"2022-08-10 21:00:51.000000000","message":"This needs to be expanded as central will need to be updated (maybe a new backend driver created) to send the NOTIFY for the catalog zone when a new zone is created. It will also need to be pool-catalog zone aware.","commit_id":"9c25eaa6006189942593f819ef54e0d9284b5021"},{"author":{"_account_id":11628,"name":"Michael Johnson","email":"johnsomor@gmail.com","username":"johnsom"},"change_message_id":"c817c9f59d18e2be850be2aba8b4f376574cff08","unresolved":true,"context_lines":[{"line_number":95,"context_line":"require individual zone creation."},{"line_number":96,"context_line":""},{"line_number":97,"context_line":""},{"line_number":98,"context_line":"Other Changes"},{"line_number":99,"context_line":"-------------"},{"line_number":100,"context_line":""},{"line_number":101,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"7bfeeba3_cce2c0af","line":98,"updated":"2022-08-10 21:00:51.000000000","message":"I am assuming here that there will be a \"catalog zone\" per designate \"pool\".\nWe need to describe how that mapping will be done.","commit_id":"9c25eaa6006189942593f819ef54e0d9284b5021"},{"author":{"_account_id":32755,"name":"Christian Rohmann","email":"christian.rohmann@inovex.de","username":"frittentheke"},"change_message_id":"bd08ab9b691e055663c645a37281ed790889d65b","unresolved":true,"context_lines":[{"line_number":95,"context_line":"require individual zone creation."},{"line_number":96,"context_line":""},{"line_number":97,"context_line":""},{"line_number":98,"context_line":"Other Changes"},{"line_number":99,"context_line":"-------------"},{"line_number":100,"context_line":""},{"line_number":101,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"8326c9ac_27570364","line":98,"in_reply_to":"7bfeeba3_cce2c0af","updated":"2022-08-25 12:48:22.000000000","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.","commit_id":"9c25eaa6006189942593f819ef54e0d9284b5021"},{"author":{"_account_id":11628,"name":"Michael Johnson","email":"johnsomor@gmail.com","username":"johnsom"},"change_message_id":"c817c9f59d18e2be850be2aba8b4f376574cff08","unresolved":true,"context_lines":[{"line_number":97,"context_line":""},{"line_number":98,"context_line":"Other Changes"},{"line_number":99,"context_line":"-------------"},{"line_number":100,"context_line":""},{"line_number":101,"context_line":""},{"line_number":102,"context_line":"Alternatives"},{"line_number":103,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":3,"id":"a30aef34_9f5fe947","line":100,"updated":"2022-08-10 21:00:51.000000000","message":"I think we will need to define a new backend driver for this. We would also need to document the pool configuration settings for this driver.\nMuch like the bind definition:\nhttps://docs.openstack.org/designate/latest/admin/backends/bind9.html","commit_id":"9c25eaa6006189942593f819ef54e0d9284b5021"},{"author":{"_account_id":11628,"name":"Michael Johnson","email":"johnsomor@gmail.com","username":"johnsom"},"change_message_id":"c817c9f59d18e2be850be2aba8b4f376574cff08","unresolved":true,"context_lines":[{"line_number":99,"context_line":"-------------"},{"line_number":100,"context_line":""},{"line_number":101,"context_line":""},{"line_number":102,"context_line":"Alternatives"},{"line_number":103,"context_line":"------------"},{"line_number":104,"context_line":""},{"line_number":105,"context_line":"Providing the means to allow backends to pull a list of their zones"}],"source_content_type":"text/x-rst","patch_set":3,"id":"2419cbec_256a153e","line":102,"updated":"2022-08-10 21:00:51.000000000","message":"I think there are two clear alternatives that could be documented here:\n1. Use the exist methods for zone management via the backend drivers.\n2. Create the catalog zone via the Designate API manually.","commit_id":"9c25eaa6006189942593f819ef54e0d9284b5021"},{"author":{"_account_id":11628,"name":"Michael Johnson","email":"johnsomor@gmail.com","username":"johnsom"},"change_message_id":"c817c9f59d18e2be850be2aba8b4f376574cff08","unresolved":true,"context_lines":[{"line_number":111,"context_line":"agreed interface to make this data available via AXFR and to various DNS"},{"line_number":112,"context_line":"servers."},{"line_number":113,"context_line":""},{"line_number":114,"context_line":"There is no real alterative to providing a catalog zone, as it is a"},{"line_number":115,"context_line":"distinct data model and protocol to be then provided by Designate."},{"line_number":116,"context_line":""},{"line_number":117,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"411992ac_56af94fc","line":114,"updated":"2022-08-10 21:00:51.000000000","message":"I disagree that there is no alternative. We are doing zone management today via an alternative mechanism.","commit_id":"9c25eaa6006189942593f819ef54e0d9284b5021"},{"author":{"_account_id":32755,"name":"Christian Rohmann","email":"christian.rohmann@inovex.de","username":"frittentheke"},"change_message_id":"bd08ab9b691e055663c645a37281ed790889d65b","unresolved":true,"context_lines":[{"line_number":111,"context_line":"agreed interface to make this data available via AXFR and to various DNS"},{"line_number":112,"context_line":"servers."},{"line_number":113,"context_line":""},{"line_number":114,"context_line":"There is no real alterative to providing a catalog zone, as it is a"},{"line_number":115,"context_line":"distinct data model and protocol to be then provided by Designate."},{"line_number":116,"context_line":""},{"line_number":117,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"e7694f03_d1177130","line":114,"in_reply_to":"411992ac_56af94fc","updated":"2022-08-25 12:48:22.000000000","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.","commit_id":"9c25eaa6006189942593f819ef54e0d9284b5021"}]}