Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Discussion] split source builds #1447

Closed
szuecs opened this issue Feb 26, 2020 · 4 comments
Closed

[Discussion] split source builds #1447

szuecs opened this issue Feb 26, 2020 · 4 comments
Assignees

Comments

@szuecs
Copy link
Contributor

szuecs commented Feb 26, 2020

Based on #1403 (comment) 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
Copy link

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

@Raffo
Copy link
Contributor

Raffo commented Mar 26, 2020

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
Copy link

mazzy89 commented Mar 29, 2020

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
Copy link
Contributor

Raffo commented May 25, 2020

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

@Raffo Raffo closed this as completed May 25, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants