-
Notifications
You must be signed in to change notification settings - Fork 4.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
v1/catalog/service/:name?tag=xxx incorrectly filters results with <=1.2.3 clients and >=1.3.0 server #4922
Comments
@agy thanks for the report! This does seem to be a bug in the changes to tags - we missed the migration case. Thanks to @Aestek's PR we can hopefully get a fix into the 1.4.0 final release (due very soon) we'll also consider a backport of the patch to 1.3.x |
@banks Did this make it in to the 1.4.0 release? I couldn't find anything in the release notes. I'm having (potentially) the same issue but in my case I have a server on 1.1.0 and a client on 1.4.0. When I query
on the client I get no services back. If I do the same query on a client running 1.2.2 I get the expected response of 1 service. |
@pvandervelde increasing versions number should always be performed by upgrading servers first, otherwise ascending compatibility cannot be achieved. |
@pierresouchay Oh crap I didn't know that. Thanks for that information. I shall make sure to actually read the documentation next time. I have downgraded the clients, so I will upgrade the servers first. |
Overview of the Issue
Following the suggested guidelines for upgrading a Consul cluster, I first upgraded my servers to 1.3.0 before starting on the clients.
After upgrading my servers to Consul 1.3.0 I noticed that client queries to
v1/catalog/service:name?tag=xxx
started returning all nodes with the configured service and not only the nodes running the service with the specified tag.All the client nodes are running Consul 1.2.3 and have the service configured using a local service definition file.
Querying the similar
health
endpoint filters the results as expected.Once the clients are upgraded to 1.3.0, this issue goes away on those clients. Clients remaining on 1.2.3 still have the issue.
What I see:
What I expect:
This issue goes away after upgrading the clients to >= 1.3.0
Reproduction Steps
Steps to reproduce this issue:
1.2.3
and 1 server nodes running1.3.0
foo
) on the clients using a service definition filecurl localhost:8500/v1/catalog/service/foo?tag=notexist | jq .[].ID | wc -l
Example service definition file:
Consul info for both Client and Server
Note: This is on a test setup in order to reproduce
Client info
Server info
Operating system and Environment details
OS: Ubuntu 18.04 (and 16.04)
Architecture: amd64
Environment: AWS EC2
Log Fragments
Included logs for completeness, but there isn't anything useful:
Client logs (at TRACE level):
The text was updated successfully, but these errors were encountered: