search

haproxytech / dataplaneapi

HAProxy Data Plane API
https://www.haproxy.com/documentation/dataplaneapi/
Apache License 2.0
322 stars 74 forks source link

Add support for SRV records #35

Closed mikeblum closed 3 years ago

mikeblum commented 4 years ago

Based on the documentation for backends and servers: CreateBackend there doesn't appear to be a way to configure a server-template for a HAProxy backend. Could this be added to the road map to support more graceful service discovery? The use-case surrounds using Consul SRV DNS to resolve services: Service Discovery with Runtime API. Since backends can't be created with the runtime API that leaves the dataplane API.

bedis commented 4 years ago

Hi @mikeblum

We don't want to add support for SRV records in the dataplane-api for 2 reasons (but opened to discussion of course):

  1. we believe that consul should be supported through a dedicated integration, like we have for kubernetes. such integration should rely on the client native library (https://github.com/haproxytech/client-native)
  2. Consul provide API hooks which allows being pro-actively updated when a change occurs somewhere and so, using the solution can reflect those changes in HAProxy using the client-native library (as well as through the runtime API)
Elufimov commented 4 years ago

Hi @bedis It would be cool if dataplane-api would be a universal entrypoint for integrations. Using native client on go is unacceptable in many cases. Rest api is far more flexible.

bedis commented 4 years ago

I meant having a dedicated client for Consul integration which would take care of your requirements above. When you use Consul, you're not supposed to use the dataplane-api at the same time.

Elufimov commented 4 years ago

I can assume that building integrations based on dataplane-api (http api) is more promising that building it based on go client. There are far more people who could use any http tool (curl, wget, ...) and any programming language that can send http requests to build any kind of integration, then people who know golang. I personally prefer dotnet over go, and we use dotent internally also. I believe that stable and fully functional http api will be great additional to haproxy.

bedis commented 4 years ago

Well, if we do ship a golang binary which does everything for consul already, in a fully turnkey way?

Now, if you tell me that you need server-template and SRV records for any kind of integration which is not mandatory Consul based, then I would agree with you ;)

bedis commented 4 years ago

Found this quote in the CoreDNS book: "In Kubernetes SRV records, the priority and weight are meaningless"

Daniel sent a patch on the mailing list to add a flag to ignore SRV record weight, so you could use it soon :)

Elufimov commented 4 years ago

I personally not talking about consul integration, but in more general sense. I just do not get it why limit managed primitives based on logic that some integrations meant to be done using native golang code. http api is far more simpler to deal with for people who just want to integrate with haproxy and do not want to learn golang for that.

bedis commented 4 years ago

You mention Consul in the first post, hence my understanding was biaised :)

So @mjuraga I think this feature makes sense in the dataplane-api since it's not only related to Consul, but target any type of deployment.

bedis commented 4 years ago

@mjuraga If you don't mind, I'd like to contribute it myselft :)

mjuraga commented 4 years ago

I absolutely don't mind. The basis for every integration is our go library haproxytech/client-native and then we reuse that logic in the dataplaneapi. So for Consul integration mentioned in the first post by @mikeblum the way to go is for us to develop the solution based on our go library. We can then reuse that logic in the dataplaneapi as @Elufimov mentioned.

pierresouchay commented 4 years ago

Daniel sent a patch on the mailing list to add a flag to ignore SRV record weight, so you could use it soon :)

So, since it is meaningless, they put crap in it? Why having a patch to ignore? wtf...

mjuraga commented 4 years ago

We support the init-addr option on server and default-server in commit https://github.com/haproxytech/dataplaneapi/commit/2622bb6e6925af304f6b86d547c2bdca27e85507

We are still working on adding the resolvers section

mjuraga commented 4 years ago

We now support the resolvers section from commit 84b3a0a2afcfc06a66b51092150ada92cfa0183d. A new release is just a couple of weeks away.

nicodeg87 commented 4 years ago

Hi guys,

I do not see the option on API spec docs to add server-template to a backend to discover SRV records. Is it possible? This would be very useful for AWS ECS where we have DNS service discovery and we need to automate the addition of new services without the need of changing and deploying manually haproxy every time we have a new service.

Thanks.

mjuraga commented 4 years ago

We do not support adding server-template yet, we'll add that to the roadmap for future releases.

f-leclere commented 3 years ago

@mjuraga did you have release roadmap for these evolution ?

aiharos commented 3 years ago

@f-leclere the feature missed this latest release but we expect it might be ready for the next one.

mjuraga commented 3 years ago

We added support for server-templates and it is expected to be in the next v2.4.0 release.