[designate] Proposal to deprecate the agent framework and agent based backends
TLDR: The Designate team would like to deprecate the backend agent framework and the agent based backends due to lack of development and design issues with the current implementation. The following backends would be deprecated: Bind9 (Agent), Denominator, Microsoft DNS (Agent), Djbdns (Agent), Gdnsd (Agent), and Knot2 (Agent). Designate includes many backend DNS server drivers[1], many of which are "native" (also known as xfr type backends) backend implementations. In addition to the "native" backends, Designate has an agent backend[2] that supports other backends via an agent process. To quote the agent backend documentation[2]: This backend uses an extension[3] of the DNS protocol itself to send management requests to the remote agent processes, where the requests will be actioned. The rpc traffic between designate and the agent is both unauthenticated and unencrypted. Do not run this traffic over unsecured networks. Here are the reasons we are proposing to deprecate the agent framework now: 1. The agent protocol used by Designate is using an "unassigned"[4][5] DNS opcode (14) that is causing problems with the dnspython library >= 2.3.0 which is now validating the opcode when building DNS messages. It is a bad practice to use "unassigned" values as they may be officially assigned at any time, likely with an incompatible message format. 2. The agent backends are not tested in the OpenStack jobs[1]. 3. Many of the agent backends have been marked as "Experimental" since 2016 with no additional contributions beyond general repository code maintenance. 4. The protocol between the Designate worker process and the agent process is unauthenticated and unencrypted. 5. We do not know of a development resource to rewrite the agent framework protocol to address issue #1 and #4 above. 6. The introduction of catalog zones[6] may eliminate the need for some of the agent based backend drivers. By marking the agent framework and agent based backends "deprecated" in the Antelope cycle, we would remove the code no earlier than the "C" release of OpenStack (per the OpenStack deprecation policy[7]). In the meantime, issue #1 has been worked around by overriding the dnspython opcode validation[7] as needed in the Designate code (similar to a monkey patch). This is not a sustainable long term solution. The following backend agent based drivers would be marked "deprecated" in addition to the agent framework itself: Bind9 (Agent) Denominator Microsoft DNS (Agent) Djbdns (Agent) Gdnsd (Agent) Knot2 (Agent) We plan to propose patches for the deprecation over the next week, but will not merge them until at least January 24th to allow time for comment from the community. If you have concerns about this deprecation plan or are interested in rewriting the agent framework protocol to address the above issues, please reply to this announcement. Michael [1] https://docs.openstack.org/designate/latest/admin/support-matrix.html [2] https://docs.openstack.org/designate/latest/admin/backends/agent.html [3] https://github.com/openstack/designate/blob/master/designate/backend/private... [4] https://www.rfc-editor.org/rfc/rfc6895.html#section-2.2 [5] https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-par... [6] https://www.ietf.org/archive/id/draft-ietf-dnsop-dns-catalog-zones-08.txt [7] https://docs.openstack.org/project-team-guide/deprecation.html [8] https://review.opendev.org/c/openstack/designate/+/870678
On 1/17/23 01:52, Michael Johnson wrote:
TLDR: The Designate team would like to deprecate the backend agent framework and the agent based backends due to lack of development and design issues with the current implementation. The following backends would be deprecated: Bind9 (Agent), Denominator, Microsoft DNS (Agent), Djbdns (Agent), Gdnsd (Agent), and Knot2 (Agent).
Hi Michael, Thanks for this. Now, if we're going to get rid of the code soonish, can we just get rid of the unit tests, rather than attempting to monkey-patch dnspython? That feels safer, no? With Eventlet, I have the experience that monkey patching is dangerous and often leads to disaster. Cheers, Thomas Goirand (zigo)
To maintain compatibility and support for the agent framework for the two release cycles required of the deprecation process, we will need to do the monkey patching (it turns out it's an enum class, so a bit more than a simple monkey patch) for the two depreciation cycles. There is definitely a risk that dnspython will change again in a way that breaks the monkey patch, but we have a check job that runs with the most recent version of dnspython, so we should catch any RCx releases that cause us problems. In fact, that job did catch this issue, but unfortunately it was over the holiday so we didn't get on top of it as quickly as we'd hoped. Michael On Tue, Jan 17, 2023 at 1:16 AM Thomas Goirand <zigo@debian.org> wrote:
On 1/17/23 01:52, Michael Johnson wrote:
TLDR: The Designate team would like to deprecate the backend agent framework and the agent based backends due to lack of development and design issues with the current implementation. The following backends would be deprecated: Bind9 (Agent), Denominator, Microsoft DNS (Agent), Djbdns (Agent), Gdnsd (Agent), and Knot2 (Agent).
Hi Michael,
Thanks for this.
Now, if we're going to get rid of the code soonish, can we just get rid of the unit tests, rather than attempting to monkey-patch dnspython? That feels safer, no? With Eventlet, I have the experience that monkey patching is dangerous and often leads to disaster.
Cheers,
Thomas Goirand (zigo)
Hey Michael, openstack-discuss, On 17/01/2023 01:52, Michael Johnson wrote:
6. The introduction of catalog zones[6] may eliminate the need for some of the agent based backend drivers.
I proposed the spec to have catalog zone support added to Designate, see https://review.opendev.org/c/openstack/designate-specs/+/849109. Thanks for taking the time to discuss this at the PTG and for all your work that went into refining the spec. May I kindly as how you feel about potential acceptance / merge of this spec in the near future? 1) I did leave a few remarks in regards to the implementation though which we could discuss. 2) I certainly am still a strong promoter of this standardized approach to distribute the list of zones to secondary servers as there already is native support in major DNS servers. But I also believe having support for catalog zones already available while still working through the deprecation phase of the agent based backends would provide people with a new option to adapt their setups to. And there is the option to not only use catalog zones within the actual secondary DNS server software, but to use it as source for some platform-specific provisioning code or agent to access the zone catalog. Regards Christian
Hi Christian, I replied in the spec comments this week that I will be reviewing your feedback. It dropped off my radar over the holiday unfortunately. I also completed my followup to your comments today and posted those as well (we were probably typing at the same time, lol). Personally I think the specification is very close to being complete, I think we just need to agree on these last few design items and we can push for reviews. As I was looking at these agent based drivers, it was very obvious that the catalog zones may eliminate the need for some of the agent based drivers. That is awesome and your proposal to add catalog zone support is perfectly timed. Michael On Wed, Jan 18, 2023 at 2:19 PM Christian Rohmann <christian.rohmann@inovex.de> wrote:
Hey Michael, openstack-discuss,
On 17/01/2023 01:52, Michael Johnson wrote:
6. The introduction of catalog zones[6] may eliminate the need for some of the agent based backend drivers.
I proposed the spec to have catalog zone support added to Designate, see https://review.opendev.org/c/openstack/designate-specs/+/849109.
Thanks for taking the time to discuss this at the PTG and for all your work that went into refining the spec. May I kindly as how you feel about potential acceptance / merge of this spec in the near future?
1) I did leave a few remarks in regards to the implementation though which we could discuss.
2) I certainly am still a strong promoter of this standardized approach to distribute the list of zones to secondary servers as there already is native support in major DNS servers. But I also believe having support for catalog zones already available while still working through the deprecation phase of the agent based backends would provide people with a new option to adapt their setups to. And there is the option to not only use catalog zones within the actual secondary DNS server software, but to use it as source for some platform-specific provisioning code or agent to access the zone catalog.
Regards
Christian
Hey Michael, On 18/01/2023 23:50, Michael Johnson wrote:
Personally I think the specification is very close to being complete, I think we just need to agree on these last few design items and we can push for reviews.
As I was looking at these agent based drivers, it was very obvious that the catalog zones may eliminate the need for some of the agent based drivers. That is awesome and your proposal to add catalog zone support is perfectly timed.
Michael
On Wed, Jan 18, 2023 at 2:19 PM Christian Rohmann <christian.rohmann@inovex.de> wrote:
Hey Michael, openstack-discuss,
On 17/01/2023 01:52, Michael Johnson wrote:
6. The introduction of catalog zones[6] may eliminate the need for some of the agent based backend drivers. I proposed the spec to have catalog zone support added to Designate, see https://review.opendev.org/c/openstack/designate-specs/+/849109.
May I ask what the intended way forward with implementing the newly merged "catalog zones spec" is? Is this targeting the Bobcat release? Regards Christian
Hi Christian, We just had the virtual PTG last week and discussed this topic[1]. As you know, we completed the specification document and merged it during Antelope. So the community agrees on the plan to implement. At this point it just needs developers to start work on the patches. During the PTG session no one attending was able to pick up this specification for development, so we did not highlight it as a feature targeted for Bobcat. I did say that I am willing to help anyone that has developer resources work on it, I just cannot lead that effort during Bobcat. So if you are willing to work on the patches, we will help out as we can with reviews and answering questions, etc. Michael [1] https://etherpad.opendev.org/p/march2023-ptg-designate On Mon, Apr 3, 2023 at 12:36 AM Christian Rohmann <christian.rohmann@inovex.de> wrote:
Hey Michael,
On 18/01/2023 23:50, Michael Johnson wrote:
Personally I think the specification is very close to being complete, I think we just need to agree on these last few design items and we can push for reviews.
As I was looking at these agent based drivers, it was very obvious that the catalog zones may eliminate the need for some of the agent based drivers. That is awesome and your proposal to add catalog zone support is perfectly timed.
Michael
On Wed, Jan 18, 2023 at 2:19 PM Christian Rohmann <christian.rohmann@inovex.de> wrote:
Hey Michael, openstack-discuss,
On 17/01/2023 01:52, Michael Johnson wrote:
6. The introduction of catalog zones[6] may eliminate the need for some of the agent based backend drivers.
I proposed the spec to have catalog zone support added to Designate, see https://review.opendev.org/c/openstack/designate-specs/+/849109.
May I ask what the intended way forward with implementing the newly merged "catalog zones spec" is? Is this targeting the Bobcat release?
Regards
Christian
Hey Michael, On 03/04/2023 16:51, Michael Johnson wrote:
We just had the virtual PTG last week and discussed this topic[1]. [1]https://etherpad.opendev.org/p/march2023-ptg-designate
Sorry I missed that opportunity to ask / discuss there.
As you know, we completed the specification document and merged it during Antelope. So the community agrees on the plan to implement. At this point it just needs developers to start work on the patches.
During the PTG session no one attending was able to pick up this specification for development, so we did not highlight it as a feature targeted for Bobcat. I did say that I am willing to help anyone that has developer resources work on it, I just cannot lead that effort during Bobcat.
So if you are willing to work on the patches, we will help out as we can with reviews and answering questions, etc.
I started a discussion internally about devoting some hours to at least get this off the ground. Does this spec need a "move" to Bobcat or other planning or acceptance process to aim for that release instead of Antelope? And I am in no way asking for a fast-lane or special treatment. I would just like to be able advertise this as: "If we write the code, someone is going to look at it and helps to get this merged for Bobcat." Thanks for the fruitful discussions and again for picking up on this whole idea. Christian
Comments below, Michael On Mon, Apr 3, 2023 at 10:56 AM Christian Rohmann <christian.rohmann@inovex.de> wrote:
Hey Michael,
On 03/04/2023 16:51, Michael Johnson wrote:
We just had the virtual PTG last week and discussed this topic[1]. [1]https://etherpad.opendev.org/p/march2023-ptg-designate
Sorry I missed that opportunity to ask / discuss there.
As you know, we completed the specification document and merged it during Antelope. So the community agrees on the plan to implement. At this point it just needs developers to start work on the patches.
During the PTG session no one attending was able to pick up this specification for development, so we did not highlight it as a feature targeted for Bobcat. I did say that I am willing to help anyone that has developer resources work on it, I just cannot lead that effort during Bobcat.
So if you are willing to work on the patches, we will help out as we can with reviews and answering questions, etc.
I started a discussion internally about devoting some hours to at least get this off the ground. Does this spec need a "move" to Bobcat or other planning or acceptance process to aim for that release instead of Antelope?
The spec does not need to move. We are all set to start development when someone is ready to work on it.
And I am in no way asking for a fast-lane or special treatment. I would just like to be able advertise this as: "If we write the code, someone is going to look at it and helps to get this merged for Bobcat."
I think that is a fair statement. Just note that others in the community may not have a lot of time to co-develop on it.
Thanks for the fruitful discussions and again for picking up on this whole idea.
Christian
Hey Michael, all, On 03/04/2023 20:51, Michael Johnson wrote:
I started a discussion internally about devoting some hours to at least get this off the ground. Does this spec need a "move" to Bobcat or other planning or acceptance process to aim for that release instead of Antelope? The spec does not need to move. We are all set to start development when someone is ready to work on it.
And I am in no way asking for a fast-lane or special treatment. I would just like to be able advertise this as: "If we write the code, someone is going to look at it and helps to get this merged for Bobcat." I think that is a fair statement. Just note that others in the community may not have a lot of time to co-develop on it.
We agreed to pick this up and implement the catalog zone support. So expect a change to appear for review at some point ;-) Regards Christian
On 12/04/2023 09:14, Christian Rohmann wrote:
And I am in no way asking for a fast-lane or special treatment. I would just like to be able advertise this as: "If we write the code, someone is going to look at it and helps to get this merged for Bobcat." I think that is a fair statement. Just note that others in the community may not have a lot of time to co-develop on it.
We agreed to pick this up and implement the catalog zone support. So expect a change to appear for review at some point ;-)
Just an update to our commitment: We started working on the implementation. Regards Christian
Hello, On 04/05/2023 10:07, Christian Rohmann wrote:
Just an update to our commitment: We started working on the implementation.
There now is a first iteration for support of Catalog Zones pushed: * https://review.opendev.org/c/openstack/designate/+/885594 PTAL and start commenting / reviewing so we can iron out any issues to have this ready for the Bobcat release. Regards Christian
Hey openstack-discuss, Michael, before even starting our implementation of the catalog zone feature for Designate, we discussed the availability of review capacity for this new feature: On 03.04.23 20:51, Michael Johnson wrote:
And I am in no way asking for a fast-lane or special treatment. I would just like to be able advertise this as: "If we write the code, someone is going to look at it and helps to get this merged for Bobcat." I think that is a fair statement. Just note that others in the community may not have a lot of time to co-develop on it.
We then gladly invested the time to implement and discuss the feature we anticipate to use ourselves, but which I also believe is a big improvement to the scalability and stability of provisioning the DNS secondaries. Coming back to my point ... You made clear that co-development was not very likely to happen, that was very transparent. But this discussion implied that review of a submitted implementation was something you or others in the Designate team would be willing to do. On 14.06.23 12:14, Christian Rohmann wrote:
There now is a first iteration for support of Catalog Zones pushed:
* https://review.opendev.org/c/openstack/designate/+/885594
PTAL and start commenting / reviewing so we can iron out any issues to have this ready for the Bobcat release.
The implementation, while receiving some feedback and requiring some iterations is now there for review. There is a corresponding change for devstack to support this feature, see all changes via [1]. We did miss the Bobcat release, likely for good as that gave us more time to work out the remaining issues. But now we'd really like for this feature to be finalized and merged for 2024.1. And while code has to be of good quality before being merged, at some point a feature just has to go into a release for people to actively use it in production and to be able to provide feedback on potentially missing settings or any other issues. I'd really appreciate if you or anyone from the Designate team could kindly respond on your intentions for catalog zones towards the Caracal release. Thank you and with kind regards, Christian [1] https://review.opendev.org/q/topic:%22catalog-zone%22
Hi Christian, As you know we have had a few review rounds and revisions on the catalog zones patch. This has included some good discussions that refined the feature. Thank you for your continued support of the patch and rebases. I agree that I think the patch is in the final review phase. It is my goal/intent that we get this into the Caracal release. I hope the community will support that goal in providing reviews and testing the patch. Michael On Fri, Jan 5, 2024 at 7:29 AM Christian Rohmann <christian.rohmann@inovex.de> wrote:
Hey openstack-discuss, Michael,
before even starting our implementation of the catalog zone feature for Designate, we discussed the availability of review capacity for this new feature:
On 03.04.23 20:51, Michael Johnson wrote:
And I am in no way asking for a fast-lane or special treatment. I would just like to be able advertise this as: "If we write the code, someone is going to look at it and helps to get this merged for Bobcat."
I think that is a fair statement. Just note that others in the community may not have a lot of time to co-develop on it.
We then gladly invested the time to implement and discuss the feature we anticipate to use ourselves, but which I also believe is a big improvement to the scalability and stability of provisioning the DNS secondaries. Coming back to my point ... You made clear that co-development was not very likely to happen, that was very transparent.
But this discussion implied that review of a submitted implementation was something you or others in the Designate team would be willing to do.
On 14.06.23 12:14, Christian Rohmann wrote:
There now is a first iteration for support of Catalog Zones pushed:
* https://review.opendev.org/c/openstack/designate/+/885594
PTAL and start commenting / reviewing so we can iron out any issues to have this ready for the Bobcat release.
The implementation, while receiving some feedback and requiring some iterations is now there for review. There is a corresponding change for devstack to support this feature, see all changes via [1].
We did miss the Bobcat release, likely for good as that gave us more time to work out the remaining issues. But now we'd really like for this feature to be finalized and merged for 2024.1. And while code has to be of good quality before being merged, at some point a feature just has to go into a release for people to actively use it in production and to be able to provide feedback on potentially missing settings or any other issues.
I'd really appreciate if you or anyone from the Designate team could kindly respond on your intentions for catalog zones towards the Caracal release.
Thank you and with kind regards,
Christian
participants (3)
-
Christian Rohmann
-
Michael Johnson
-
Thomas Goirand