Defining routes in service metadata

[DavidRutqvist]

Since the release of version 1.0.7 of Consul, services now have the possibility to provide arbitrary key-value attributes as service metadata. Using tags for metadata, as fabio makes use of, was the preferred way of specifying such attributes before the introduction of service metadata. However, with this new feature fabio should adopt and introduce support for specifying routes in the service metadata section since it is more well-suited.

Tags could perhaps be kept for backwards compatibility but the recommended way forward in the documentation should be to use metadata instead of tags. Since querying of metadata is not supported some "discovery tag" may still be required to avoid having to loop through all services but that could be some standard tag e.g. "fabio" or something more descriptive.

Related topic: hashicorp/consul#1107

[magiconair]

Sounds good to me. This would also fit well into the refactor of the service monitor in #564. Do you feel like submitting a PR based on that code?

[aaronhurt]

Completely removing the tag model would almost certainly break many deployments including our deployment. This would result in quite a bit of code change to solve a non-problem. I definitely see the appeal of service metadata but do not think the tag model should be abandoned.

[DavidRutqvist]

Completely removing the tag model would almost certainly break many deployments including our deployment. This would result in quite a bit of code change to solve a non-problem. I definitely see the appeal of service metadata but do not think the tag model should be abandoned.

Yeah, that is why I proposed keeping it for backwards compatibility and only changing the documentation to gradually move towards service metadata.

@magiconair I could try finding time to submit a PR. I am a bit short of time during the following weeks but we'll see. It did not seem to difficult to add this kind of support.

Any suggestions for "discovery tag". Currently fabio searches for the prefix "urlprefix-", this does not seem to be a candidate according to me.

[DavidRutqvist]

Yesterday I started implementing this. To do this we obviously have to update the Consul dependency to a later version. After doing this I realised there is a lot of changes which is not necessary to this use case. Only the newly added ServiceMeta field to the CatalogService is needed in order to fulfill this use case.

What are your thoughts on this @magiconair ? Should we update the whole API-catalog or just add the field to the CatalogService struct?

[aaronhurt]

@DavidRutqvist I'll build and test a local version with v1.4.0 to support service metadata and consul connect.

[DavidRutqvist]

@DavidRutqvist I'll build and test a local version with v1.4.0 to support service metadata and consul connect.

Super, I'll leave this to you then. It will be very much appreciated.

[aaronhurt]

I updated consul to v1.4.0 in #571

[chenjpu]

Is there progress?