Open Stack

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 at 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)
>
>