-
Notifications
You must be signed in to change notification settings - Fork 2k
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
cli: service info
command returns incorrect services in output
#19542
Comments
I can see this in 1.7.2 as well. The nomad templates are also quite messed up similar to #16616 |
Hi @blmhemu; as far as this stated issue goes, it only affects the CLI and the linked issue is a separate, non-related bug. |
I understand, but i could not repro #16616 on 1.6, only on 1.7.(2) (Let me know if I should raise another issue) Also, I assumed templates use the data published by the API and if the API provides wrong info, may be the templates are rendedered with wrong info. |
Seeing this with the
|
Still relevant^, had me wondering where did I go wrong. @jrasell are you working on this? otherwise I think I can pick this up? |
+1 on this, it's a bad issue that seems to have been included in one of the recent releases. breaks our workflow... |
Still present in 1.8.1, just ran into this |
I was taking a look into this testing with main locally and was unable to reproduce it. When looking at the code I realised PR #23502 was merged and released as part of 1.8.2 and 1.7.10+ent and is within the 1.9.x release cycle. I am therefore going to close this issue as complete. If you still come across this in a version after those detailed above, please reopen this or raise a new issue. Thanks. |
Nomad version
Issue
The
service info
command returns incorrect results when attempting to perform a simple service lookup within a particular namespace.The list output correctly lists two services registered:
When I go to lookup the
grafana-server
service I get the following result:The API is returning the correct data, so this is a problem with the command.
It seems the bug was introduced within #18836
The text was updated successfully, but these errors were encountered: