Populate Consul's ServiceMeta using service.Attrs

[dsouzajude]

Populates Consul's ServiceMeta field with Registrator's Attr so that we can query a service with additional attributes bypassing the need to use a key/value store:

Example:

Setting the following container's environment variables to the following:

• SERVICE_PROTOCOL="http"
• SERVICE_TYPE="service"

would result in: (Note the ServiceMeta field).

[{
	"ID": "26596b52-0d61-ee5c-bac2-52d66b8ee8fc",
	"Node": "test-node",
	"Address": "xxx",
	"Datacenter": "eu-west-1",
	"TaggedAddresses": {
		"lan": "xxx",
		"wan": "xxx"
	},
	"NodeMeta": {
		"consul-network-segment": ""
	},
	"ServiceID": "xxx",
	"ServiceName": "users",
	"ServiceTags": [
		"environment=devel",
		"zone=eu-west-1a"
	],
	"ServiceAddress": "xxx",
	"ServiceMeta": {
		"check_interval": "15s",
		"check_tcp": "true",
		"check_timeout": "3s",
		"protocol": "http",
		"type": "service"
	},
	"ServicePort": 16234,
	"ServiceEnableTagOverride": false,
	"CreateIndex": 4075434,
	"ModifyIndex": 4075434
}]

References #619

[Wing924]

I think

"check_interval": "15s",
"check_tcp": "true",
"check_timeout": "3s",

should not write to meta since it's internal use for registrator.

[dsouzajude]

I'm not sure if i agree, there is no harm for it being there. It will only make the solution a bit more complicating when it doesn't have to be. For example, the problem is that there is no "standard" Registrator Attrs that i can filter out - although in this case for now most of these internal Attrs are for health checking and they start with check_ but IMO it will probably be not so clean to filter these specific checks Attrs.

In the end, the consumer can choose to use it or not but there is no way for it to modify these attrs anyway. So i'm guessing it should be OK?

Will wait for more feedback if these attrs should be removed or not or we can keep it to make it simple.

[CpuID]

👏 nice progress so far :) Will be good to see this functionality in place (in some form).

[josegonzalez]

Needs documentation at least.