Multiple tag filters for ad-hoc queries w/HTTP endpoints (catalog, health)

[doertedev]

OHAI.

Am I under the correct assumption, that this means the tag filter for the HTTP API endpoint /v1/catalog/service/<service> only supports one tag filter? This would explain the problems that I'm having right now: I'm writing my services with tags for both the region and environment but filtering for both fails.

https://localhost:8500/v1/catalog/service/zookeeper?tag=region-us-east-1 5 results,
https://localhost:8500/v1/catalog/service/zookeeper?tag=region-us-east-1&tag=env-internal 5 results,
https://localhost:8500/v1/catalog/service/zookeeper?tag=env-internal 1 result,
https://localhost:8500/v1/catalog/service/zookeeper?tag=env-internal&tag=region-us-east-1 1 result.

Second get's ignored if I'm seeing this correctly.

Can we integrate multiple tag filters? Or accept a json array in the URl? Or do we already and I cannot seem to articulate my query properly? Or do you say "prepared query || gtfo"?

Thinking out loud:
When using prepared queries for all those, I'd either have to create a prepared query for all possible combinations of ["environment", "region", "service"] which would right now be 350 prepared queries for us r/n and we just started implementing consul. And another would be to create them session-bound and removing them immediately after sessionclose, which in one swing (one ansible discovery round-trip) would create overhead. I think. Haven't benched prepared queries yet (which is the reason I filed this here).

Thanks in advance,
a tableflipping german. Prost.

[doertedev]

Just found #294 ... So I guess its "prepared statements" then?

[slackpad]

Hi @doertedev sorry I think the idea of multiple tags for ad-hoc queries over HTTP endpoints like catalog are still worth considering, and got lost in #294.

[doertedev]

What do you think about JSON values? (e.g. ?tag=[eu-west-1,production]?)

[slackpad]

@doertedev I don't think I'd want to put JSON in there, the ?tag=&tag=... kind of syntax seems like the most natural.

[doertedev]

What about negation? That's why I thought about JSON.

[slackpad]

I'd still like to avoid JSON - we could using the prepared query syntax of !tag which would have a minimal amount of URL encoding, or we could do something like ?not-tag=.

[doertedev]

The only thing that really sounds wrong to me is using one URL parameter multiple times. This would maybe break third party software that constructs the URL. Anything else? Sure.

[leftyftw]

Isn't the "standard" array notation ?tag[]=value1&tag[]=value2&tag[]=value3. I believe that would suffice in this instance. Would love to see this ability.

[senthilkumarkj]

@doertedev please see this comment - #294 (comment) and this stackoverflow answer - http://stackoverflow.com/a/24728298/205585

This is the most common way and for negation we could do "!" like it is done in prepared queries or nt-tag query as @slackpad suggested.

[ffledgling]

Bump. I was looking for this and the docs I found do not explicitly mention that this is not possible at the moment. Would be neat to have this on an ad-hoc basis :)

[vanderhoofen]

It's 2018 now and the first thing my devs ask me is "how can I filter on multiple tags?" Prepared Queries create a bad user experience for such a lightweight request

[KrolikROJER]

Any news?

[abhaychaware]

Any update/example/documentation/roadmap on this ?

[adilyse]

This is now available in v1.3.0, released yesterday. Thanks for the feedback, which helps us make a better product!