Closed mikeblum closed 3 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):
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.
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.
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.
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 ;)
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 :)
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.
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.
@mjuraga If you don't mind, I'd like to contribute it myselft :)
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.
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...
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
We now support the resolvers
section from commit 84b3a0a2afcfc06a66b51092150ada92cfa0183d. A new release is just a couple of weeks away.
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.
We do not support adding server-template
yet, we'll add that to the roadmap for future releases.
@mjuraga did you have release roadmap for these evolution ?
@f-leclere the feature missed this latest release but we expect it might be ready for the next one.
We added support for server-templates
and it is expected to be in the next v2.4.0
release.
Based on the documentation for backends and servers: CreateBackend there doesn't appear to be a way to configure a
server-template
for a HAProxybackend
. 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.