Add tagged addresses for services

[mkeeler]

Currently these are not used anywhere but they will be eventually. I hooked it into the WAN address translation for both DNS and the HTTP server.

• Service Definition Docs - Updated to show that the fields exist with no other mention of why you might use them. Currently nothing does but when they do I will update these docs some more.
• consul services register - Added tagged address support
• API - Added support in both agent and catalog/health APIs to allow usage of tagged addresses.
• Config - Added necessary code to enable loading the tagged addresses for service definitions within a config.
• Structs - Added the necessary fields to several structures and updated a bunch of functions to be aware of them - like IsSame methods and conversions to/from ServiceNode/NodeService.

[banks]

Looks good. I understand that while you can add these they basically don't do anything for now right? i.e. no way to have a tagged address return from DNS rather than the existing address logic? Is it confusing that translate_wan_addrs won't actually work at the service level for now?

A couple of places I could think of that weren't in this PR but might need considering:

• TaggedAddresses will need camel case translation. It might be that it already works due to us using that field name elsewhere but an explicit test case in config tests seems important. (

  consul/agent/config/runtime_test.go

  Line 2188 in 0837e57

  desc: "translated keys",

  and

  consul/agent/agent_endpoint_test.go

  Line 2480 in 0837e57

  func TestAgent_RegisterService_TranslateKeys(t *testing.T) {

  )
• API docs for the affected endpoints? We don't list all possible fields but we could show an example of a service result with tagged addresses?
• Would be nice to have a test for the HTTP endpoint(s) that return services to show that we don't add an empty TaggedAddresses map into every response (e.g. show omitempty is set right in the relevant structs).

[mkeeler]

For the camel case thing, I tried to do it how the node level tagged addresses work. Which is in our config file you specify tagged_addresses but in the API and the main service definition in the structs package its only CamelCase. I went looking around but it didn't seem like we allowed snake case anywhere but the config. I guess the service registration is a bit different. Also we don't seem to translate keys when the v1/catalog/register endpoint is used instead of v1/agent/service/register.

I can make snake case work in those other situations easily enough as well as the rest of your points.

I went ahead and implemented the WAN addr translation as it was pretty easy. Still need a couple tests for that though.

[mkeeler]

Current TODO list:

• DNS Service Address/Port translation tests
• HTTP Service Address/Port translation tests
• Should we synthesize the "lan" address to be the service address and port?
• API docs where service tagged addresses can be used
• HTTP endpoint tests to ensure we omit the empty map properly.
• snake case for tagged addresses in the service definition.

[mkeeler]

@banks Not only did I add all the tests and ensure the snake case stuff was taken care of but I went ahead and plumbed the address translation for services into both the DNS and HTTP servers.

For DNS the precedence of addressing when querying a remote datacenter is now:

1. "wan" tagged service address
2. service address
3. "wan" tagged node address
4. node address

Before we just had layers 2-4.

Additionally for SRV records we now translate the port as well.

In the HTTP API the translation will change the service address returned and the services port. Essentially it just replaces them with the ones from the "wan" tagged address if that exists similar to how the HTTP API replaces the node address with the "wan" tagged node address.

[banks]

Wow, this looks awesome!

I verified the a.config.TranslateWANAddrs is respected as all the translation remains encapsulated in TranslateAddress* methods.

Docs updates all look great!

[banks]

Sigh... I meant the other radio button!