)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":31664,"name":"Omer Schwartz","email":"oschwart@redhat.com","username":"oschwart"},"change_message_id":"8d3accce54be89527d87edf05f1a16ca8bf2e02d","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"12affaad_ec94dfa6","updated":"2026-08-31 12:13:49.000000000","message":"Would you mind open a launchpad bug and link the patch to it?","commit_id":"9d05d01617d7dedf7ade80d4c37e2d1137a7058c"},{"author":{"_account_id":13252,"name":"Dr. Jens Harbott","display_name":"Jens Harbott (frickler)","email":"frickler@offenerstapel.de","username":"jrosenboom"},"change_message_id":"d5b9a4d34af223b7a1ca9c78b7141931f40fe199","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":3,"id":"33b877ff_49f62270","updated":"2026-09-09 13:31:01.000000000","message":"I think there are some more design decisions to be resolved before this can proceed, like shouldn\u0027t the SOA record get updated too, if NS gets updated (see also https://review.opendev.org/c/openstack/designate/+/998103)?\n\nI\u0027m also not sure whether this feature could be abused. I also don\u0027t have time to get involved more deeply in the spec discussion\n\ngiven how small the current core team is, my vote would be to reject this feature as not supportable in the current state","commit_id":"01a8699fdca494432a2b25ef38412f59e65d320d"},{"author":{"_account_id":31664,"name":"Omer Schwartz","email":"oschwart@redhat.com","username":"oschwart"},"change_message_id":"94b1aba55fc89e55caf168075deb78f81b2f327c","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"fa5b12a2_92f40cf8","updated":"2026-09-02 12:51:05.000000000","message":"It would be great if you could share opinions about the idea presented in this patch","commit_id":"01a8699fdca494432a2b25ef38412f59e65d320d"},{"author":{"_account_id":38653,"name":"Sylvain Desgrais","email":"sylvain.desgrais@gmail.com","username":"artpej"},"change_message_id":"3a848dd274a7067e5fc957888df1f273bb3a2408","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"023ec68f_4efc4846","updated":"2026-09-09 14:11:45.000000000","message":"Thanks Omer, Jens. I agree with all three points, and I don\u0027t think this\nshould go in as it stands.\n\nOn the review itself:\n\n- Omer is right about the rollback path. _add_ns/_delete_ns gating on\n  recordset.managed alone means a handed-off zone can never rejoin\n  pool-managed sync, and gating the API check on the config flag alone\n  locks admins out of an already-transitioned zone. Those are design\n  bugs, not something I should paper over in a follow-up patch set.\n- Jens is right about the SOA. If the apex NS becomes owner-managed,\n  MNAME selection (998103) and the SOA/NS coupling need an explicit\n  answer rather than implicit behaviour.\n- The abuse question is fair too. A project could advertise nameservers\n  the pool does not control while the pool\u0027s servers still answer\n  authoritatively. That needs a real policy story, an operator allow-list\n  or a dedicated role, not a global boolean.\n\nFor context, this change is one of three coming from the same use case:\n991471 (per-zone also_notify), 992594 (SOA refresh on secondary zones,\nmerged), and this one. The common thread is running a Designate pool\nalongside authoritative servers that Designate does not own.\n\nEverything Designate offers for that today is pool-scoped. ns_records,\nalso_notifies, catalog_zone and targets all live in pools.yaml, need an\nadmin and a designate-manage pool update, and apply to every zone in the\npool. That is the right granularity for a homogeneous pool, and I am not\narguing it should change. It just does not cover the case where\nindividual zones have different external nameservers, which today means\none pool per combination.\n\nOmer asked whether restricting this to PRIMARY zones was considered. It\nhas to be PRIMARY-only, because SECONDARY is not the escape hatch it\nlooks like. On master:\n\n- do_axfr() calls dns.query.xfr() with no keyring, so Designate can\n  never sign an outbound transfer. It cannot slave from a primary that\n  requires TSIG for AXFR, only from one that authorises transfers by\n  source address. Note the asymmetry: mdns does support TSIG on the\n  inbound side, when Designate is the primary being transferred from.\n  ZoneMaster carries only host and port, so there is not even a place to\n  declare which key to use.\n- zone.retry and zone.expire are stored and republished in the SOA we\n  serve, but never used anywhere. A failed transfer is logged at WARNING\n  and dropped: no retry, no status change, no expiry. A secondary zone\n  whose primary has been unreachable for weeks keeps being served, which\n  is exactly what RFC 1035 expire exists to prevent.\n- until 992594 merged, from_dnspython_zone() dropped the SOA refresh\n  field entirely, so the one timer that exists ran on a randomised local\n  value instead of what the primary advertises.\n- There is no IXFR. Every refresh is a full AXFR of the whole zone.\n- Inbound NOTIFY is authenticated by source address only.\n\nSo rather than iterate on this patch set, I would like to take the whole\nthing to openstack/designate-specs as one proposal about per-zone\nconfiguration of authoritative servers outside the pool, and let this\nchange wait on the outcome. The narrow \"make the apex NS editable\"\nframing here is the wrong shape, and the review comments above are what\nconvinced me of that.\n\nOne question that would help me scope it: what is the project\u0027s position\non the SECONDARY zone type? Is it something you would still take fixes\nfor, or is it deprecated in practice? I am happy to do the work either\nway, but the answer changes what the spec should propose.","commit_id":"01a8699fdca494432a2b25ef38412f59e65d320d"},{"author":{"_account_id":31664,"name":"Omer Schwartz","email":"oschwart@redhat.com","username":"oschwart"},"change_message_id":"2c20824b38a696ea09a43361ca62c1e91317f41e","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"ff486682_29770203","updated":"2026-09-02 12:49:37.000000000","message":"Thanks for working on this. One design concern that I have for now: disabling allow_apex_ns_edit after zones have already transitioned doesn\u0027t roll anything back — it freezes them. Here are a few things:\n\n1. _add_ns/_delete_ns gate only on recordset.managed, not on the config flag. Once a zone\u0027s apex NS is unmanaged (post hand-off), pool nameserver changes will skip it forever, regardless of whether the flag is later turned back off. There\u0027s no path for a handed-off zone to rejoin pool-managed sync.\n\n2. In recordsets.py\u0027s put_one, the apex-NS check:\nif recordset[\u0027name\u0027] \u003d\u003d zone[\u0027name\u0027]:\n    if not CONF[\u0027service:central\u0027].allow_apex_ns_edit:\n        raise exceptions.BadRequest(...)\nfires purely on type/name/config-flag, with no check of the recordset\u0027s actual managed state and no context.edit_managed_records bypass. So once the flag is disabled, an already-unmanaged (user-owned) apex NS recordset becomes uneditable via the API for everyone, including admins — there\u0027s no way to fix a stale NS list short of re-enabling the flag globally.\n   \nMaybe we could gate that check on recordset.managed rather than the config flag alone (e.g. if recordset.managed and not CONF...allow_apex_ns_edit: raise), so admins (and ideally owners) can still fix/revert already-transitioned zones after the feature is disabled. Also worth a release note calling out this rollback behavior explicitly, and it\u0027d be good to hear whether restricting this to PRIMARY zones was considered, since the SOA/NS-sync assumptions for SECONDARY zones seem incompatible with owner-managed apex NS.","commit_id":"01a8699fdca494432a2b25ef38412f59e65d320d"},{"author":{"_account_id":31664,"name":"Omer Schwartz","email":"oschwart@redhat.com","username":"oschwart"},"change_message_id":"e0322edfd0fc43df69967eb87f1c8189dd10f834","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"1b9203da_399f499e","updated":"2026-09-02 12:24:05.000000000","message":"recheck grenade failures","commit_id":"01a8699fdca494432a2b25ef38412f59e65d320d"},{"author":{"_account_id":31664,"name":"Omer Schwartz","email":"oschwart@redhat.com","username":"oschwart"},"change_message_id":"ad80f0300bb9962ca9de22bfb41bd7717cedf4b7","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":3,"id":"256aaeae_af8633da","in_reply_to":"023ec68f_4efc4846","updated":"2026-09-09 15:25:28.000000000","message":"We do accept fixes for the secondary zones. I personally do not run neither secondary nor catalog zones in production and I don\u0027t have lots of experience with neither, but of course I\u0027d consider and review fixes for it. In case you guys run it in production, your feedback will definitely be valuable.","commit_id":"01a8699fdca494432a2b25ef38412f59e65d320d"}]}