chore(openstack designate)!: remove in-tree provider

[mloiseleur]

Description

Part of #4347.
There is now a webhook provider, see #5115

Checklist

• Unit tests updated
• End user documentation updated

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please ask for approval from mloiseleur. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[ivankatliarchuk]

Do we want to remove all providers or there is a list which one we are planning to keep? And could we bump them to stable?

I'm proposing to keep

• aws
• gcp
• azure
• cloudflare
• ibm
• oracle
• pihole
• .... maybe some others

Basically, in-tree providers are great, but for security reasons I could not use them in most of the client environments. I would expect this is true for other users.

[mloiseleur]

@ivankatliarchuk This does not seem related to this PR. Wdyt of adding a comment on #4347 ?

[ivankatliarchuk]

Will do.

/lgtm

[mloiseleur]

@frittentheke Following your webhook provider, I opened this PR to remove the in-tree one. I noticed you wanted to update tutorials since all the other webhooks provide instructions on their repository, I am not sure that this is relevant.

Would you like to review this PR ?

[Raffo]

@ivankatliarchuk the idea for the webhook provider was always to remove most of the in tree providers. I can dig up the original issue and PR if you are interested, but it should be easy to find. The criteria that we wanted to follow was mostly to keep in tree everything that we considered stable and definitely provide an out of the box experience for the 3 major cloud providers. I realize myself that this seems to be privileging US big tech, but the intention was mostly to keep what is more used and more developed and not really do any favor.
The thing we got a bit stuck on executing the plan was removing the code: it didn't seem right so we wanted to move it somewhere else. But what about ownership, both legally (the code is owned by the cncf) and practically in terms of responsibilities? I think that if we find a path to just remove it gradually that would be a good way.

[ivankatliarchuk]

Yeah, this was the wrong location to ask my question

[frittentheke]

@frittentheke Following your webhook provider, I opened this PR to remove the in-tree one. I noticed you wanted to update tutorials since all the other webhooks provide instructions on their repository, I am not sure that this is relevant.

@mloiseleur we certainly can update the tutorial at https://github.com/kubernetes-sigs/external-dns/blob/master/docs/tutorials/designate.md, but this PR intends to fully remove it. Question is, if documentation on how to integrate with different providers should live in the external-dns repo or with the individual providers.

Would you like to review this PR ?

I believe this PR looks good, if you intend to remove the in-tree provider immediately.

Maybe some general communication strategy to remove the in-tree providers makes sense to deprecate them technically and maybe require some sort of additional action or command line arg (to really get peoples attention) would be good. Our webhook, while crafted with love and care, could still contain bugs and I would not want to immediately force people to use it. On the other hand there have to be some active deprecation happening, otherwise it's never going to happen :-)

[mloiseleur]

Question is, if documentation on how to integrate with different providers should live in the external-dns repo or with the individual providers.

For all the other providers, the documentation specific to the provider is directly on the provider repository. With current documentation system of external-dns it's only the last tagged version that is hosted on https://kubernetes-sigs.github.io/external-dns/.
=> If a provider has multiple releases between two version of external dns, the documentation would not be updated (!).
=> So yes, let's keep provider documentation on provider repository

I would not want to immediately force people to use it.

We do not have any way to force people, AFAIK. Users can still use last version with in-tree providers if they need, as long as they need. And they can also already use this webhook provider with latest release of external-dns.
Anyway, we can wait a bit longer and see if there is any blockers.
=> In the meantime, may I suggest you to invite users connected on kubernetes slack (#external-dns) to test https://github.com/inovex/external-dns-designate-webhook ?

[mloiseleur]

/hold