What did you do?
The changes from #17349 break Consul service discovery because the filter selectors available to the Catalog API are not the same as for the Health API. For example, prior to 3.11.0, a filter containing ServiceTags as the selector - which is completely valid for the Catalog filtering - breaks service discovery entirely, as it is not valid for the Health API (rather Service.Tags is for Health). The documentation on the Prometheus website even reference the filtering for the Catalog API explicitly:
# A Consul Filter expression used to filter the catalog results
# See https://www.consul.io/api-docs/catalog#list-services to know more
# about the filter expressions that can be used.
With invalid selectors, Consul rejects requests entirely.
What did you expect to see?
Consul SD still works with filter expressions containing ServiceTags
What did you see instead? Under which circumstances?
It doesnt
What did you do?
The changes from #17349 break Consul service discovery because the filter selectors available to the Catalog API are not the same as for the Health API. For example, prior to 3.11.0, a
filtercontainingServiceTagsas the selector - which is completely valid for the Catalog filtering - breaks service discovery entirely, as it is not valid for the Health API (ratherService.Tagsis for Health). The documentation on the Prometheus website even reference the filtering for the Catalog API explicitly:With invalid selectors, Consul rejects requests entirely.
What did you expect to see?
Consul SD still works with
filterexpressions containingServiceTagsWhat did you see instead? Under which circumstances?
It doesnt