External-dns: [Discussion] split source builds

[szuecs]

Based on https://github.com/kubernetes-sigs/external-dns/issues/1403#issuecomment-581865853 and a discussion with @Raffo , we wanted to kick off a discussion about how to enable CRDs in general.

As @Raffo points out including CRDs in package source was maybe a mistake.

There were 2 ideas pointed out: try plugins or build tags:

1. My experience with Go plugins is that they are not very stable. In the past they only worked on Linux as far as I see now they support Mac OS, too. Plugins had to be compiled with the binary in the same build tree and was dependent on paths, which made it a pain to use. Maybe this changed. Best integration would be to build a plugin and use some cli parameter in external-dns to pass it. Delivery could be a volume mount with the plugin.
2. Build tags would be used to have a clean core build, but then everyone would have to build their binary and create containers for their users. An obvious question would be, do we build more than the core docker containers?

Another idea would be:

1. Refactor external-dns to be library first, such that providers can integrate their source/provider themselves. I have a good experience with https://github.com/zalando/skipper, to enable the users to build their own integrations with that design. This would require the most work, but would be also the most powerful one.

I think the current strategy, "accept everything which is good enough from code point of view", seems to be the best for the users.
Maybe this is not the best for maintainers?!

I am not sure how to proceed.

[ilackarms]

i'm not sure what the path forward looks like for a provider like Gloo with this model. please advise

[Raffo]

I am considering playing with https://github.com/hashicorp/go-plugin as well before proposing a solution.

After a quick investigation, I think that (1) is not viable and that (2) is nice, but also slightly more complicated than needed.

accept everything which is good enough from code point of view

I think this is what we have been going with till now and it's starting to become a mess, this is why I would love to have something that solves the problem, but I do realize it could cause problems to users adopting ExternalDNS.

[mazzy89]

I like option 3 and what I would imagine here would be to empower the users to create their own controller managers for their CRDs and use External-DNS imported as a library inside the controller manager.

[Raffo]

For now we'll go on with #1558, which is partially done. I'm closing this one.