Inject tags into SRV records

[ardichoke]

Feature Description

Currently, SRV records for a service can only be separated out by changing the service name. This is not possible in some cases (for instance, Puppet uses _x-puppet._tcp.[srv_domain] for service discovery, and there is no way to change anything other than the [srv_domain] portion). Consul already allows for getting A records in the form of .<.tag>.service<.domain>, doing the same with automatic SRV records would bring this into parity with the A records and allow for services to separate clusters.

Use Case(s)

This can be used any time multiple separate clusters need provide the same service but must be kept separate during discovery. In the example above of using Puppet, when upgrading from one major Puppet version to another, the ability to tag the version number that a node is providing would make it so clients can be moved between the older and newer revision in a controlled manner.

[jkirschner-hashicorp]

Hi @ardichoke,

If I understand correctly, you want to use an RFC 2782 SRV lookup with Consul DNS? That is already supported, e.g.,

dig @127.0.0.1 -p 8600 _rabbitmq._amqp.service.consul SRV

where the service is rabbitmq and tag is amqp.

The full format is _<service>._<protocol>[.service][.datacenter][.domain] where <protocol> can be either (1) a tag, or (2) tcp for no tag.

Is this what you were looking for? If so, where were you looking in the docs for this info / is there something we could make clearer? Thanks!

[ardichoke]

I'm aware that's already supported in the way you listed, what I'm proposing is an enhancement to how this works. Perhaps a more concrete example would help. What I've run into is an issue with Puppet specifically, which requires that the service and protocol be _x-puppet._tcp

When deploying an updated version of puppet server, there's no way to differentiate, based on tags, between the servers providing the old version and the servers providing the new version. It would be much more useful if Consul used tags in SRV records the same way it uses them in the service A records.

Specifically, If you have the x-puppet service, with a tag of v7, return SRV records for this:

dig @127.0.0.1 -p 8600 _x-puppet._tcp.v7.service.consul SRV

[ardichoke]

As an addendum, it doesn't really make sense to insert tags into the protocol portion of a SRV record, as protocol has a specific meaning whereas a tag can be anything. It seems like it would make more sense to have a separate configuration option for a service that allows you to specify which protocol(s) that service supports, which is then used to override the _proto portion of the DNS entry.

[jkirschner-hashicorp]

Hi @ardichoke,

Thank you for the clarification - the concrete example really helped!

Note for future readers When considering how to approach this enhancement request, we'd need to ensure it would be backwards compatible with the current behavior - which was implemented in this PR from 2014. For example, to maintain backwards compatibility in Consul Enterprise when only one of datacenter or namespace is included as a label (but not both), the prefer_namespace agent configuration flag is needed to disambiguate whether that single label is for a datacenter or a namespace.

e.g.,

_<service>._<protocol>[.service][.datacenter][.domain]        # current behavior
_<service>._<protocol>[.tag][.service][.datacenter][.domain]  # suggestion from original poster

[jkirschner-hashicorp]

Hi @ardichoke,

What are your thoughts on PR #13993 and its suitability for what you were hoping to accomplish? Here's the associated docs preview.

Given a service named x-puppet with a tag v7, you could perform an RFC 2782 style lookup using _x-puppet._tcp.v7.service.consul.

The Consul engineering team still needs to perform review of that PR and decide whether that approach for including tags is the way we should proceed. But before that, I want to understand whether or not the PR would meet your needs.

[ardichoke]

I'm not familiar enough with the codebase to comment on the actual code change itself, but from the description of the PR, yes, that seems like exactly why I had hoped for. Thanks.