buraksezer / olric

Distributed in-memory object store. It can be used as an embedded Go library and a language-independent service.
Apache License 2.0
3.05k stars 114 forks source link

DNS based service discovery #224

Open luisdavim opened 1 year ago

luisdavim commented 1 year ago

Hi, this relates to https://github.com/buraksezer/olric/issues/195 but it's more of a feature request.

I know tool/library supports different service discovery mechanisms through plugins but it would be nice to have one working out of the box without needing any plugins.

I think DNS would be perfect for that, it can be used with consul, kubernetes and any cloud provider and since the implementation can be done using the standard library, it doesn't require any additional dependencies.

buraksezer commented 1 year ago

Hey @luisdavim,

Thank you for reporting this. It would be good having a default implementation based on DNS. Olric already depends on (indirectly) github.com/miekg/dns. I think this task can be a good first issue. Please feel free to provide a design document and create a PR for this feature.

kozlowsqi commented 9 months ago

Is this still relevant?

I am looking for my first issue and this seems easy enough.

luisdavim commented 9 months ago

Yes, I think this is still relevant.

buraksezer commented 9 months ago

Is this still relevant?

I am looking for my first issue and this seems easy enough.

Hello,

Yes, it's still relevant but we should start working on an RFC before implementing the feature.

kozlowsqi commented 9 months ago

Ok. I am sorry but I am not sure what you mean by an RFC.

If I understood this issue correctly, what you want is something similar to how nginx dns service discovery works.

My initial idea is to implement the ServiceDiscovery interface and simply create a default plugin for service discovery.

However I am quite green and would appreciate some guidance.

luisdavim commented 9 months ago

Plugins for service discovery already exist. The point of this issue is to have a native, default service discovery mechanism.

See also:

kozlowsqi commented 9 months ago

Plugins for service discovery already exist. The point of this issue is to have a native, default service discovery mechanism.

If I understand it correctly, plugins for service discovery are written in Go, and they implement an interface from here. That package is the common dependency between orlic and service discovery plugin (orlic consumes the interface, the plugin implements it).

All I would need to do is provide a default implementation that is used instead where appropriate. Am I on the right track here?

luisdavim commented 8 months ago

The idea is that we would have a default service discovery mechanism based on DNS, without having to use plugins.

An RFC (request for comments) is a document where you would explain the proposed implementation so it cabeceiras reviewed and agreed upon before starting the actual implementation.