Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
target grains ip_interface no return received #49626
Description of Issue/Question
I need to list those machines that are located in a certain network. For this I usually use the grains ip_interfaces and so far it has worked for me; but I'm currently getting the following error when I try to list the machines.
Filtering the logs I see the following error message
However, when I consult for other grains; for example kernel, I get the machine listing
Steps to Reproduce Issue
Thanks a lot
i'm having a hard time replicating this:
Did you recently upgrade? i'm also wondering if there is something in the minion cache from teh older minion versions that is possibly causing the issue
@Ch3LL Thanks for answering so fast!!!
Yes, im recently upgrade the master.
My salt infrastructure is extensive (about 800 minions). I have filtered by the salt version to go over the grains ip_interfaces and I have not obtained any error information in the logs.
An example of 2014 versions:
An example of 2015 versions:
I have also tried to empty the cache of all the minions by removing the directory:
and forcing the update using the command:
Can I perform some command to get a more accurate debug of the targetting functions?
Thanks a lot!!
Checking the information of some windows servers I have verified that the name of the network interface has extended ASCII characters:
Can this be the cause of the exception that appears in the salt logs?
thanks for tracking that down. i believe thats exactly the issue.
I was able to replicate by hacking the code with:
ping @terminalmage any ideas here?
Sep 25, 2018
The matching system was not intended to support multiple wildcards like this. The wildcard only works when it's in the value being matched, not in any of the intermediate nested levels of keys. To make it work for intermediate nested levels would require some significant restructuring, which would need to be done in a future feature release.
I have a question though: Were you aware that there is a subnet matcher? This would seem to be a much easier way of doing what you want:
The subnet matcher I understand is for the service IPs of the agent, right? my agents have different network interfaces: the service interface and a couple of non-routed network interfaces (NFS, etc).
Using network identification can I interrogate my agents for those interfaces that are NOT routed?
Yes, it should still work. Did you try it?
AH! I found the problem. So yes, wildcard matching was indeed added at some point, but while I was in the process of writing new unit tests for this I discovered a completely unrelated bug! If the data being matched on the level after the wildcard is the value side of a key/value pair in a dict, the match fails. However, when it's a list (as in your example) the match succeeds.
I'm working on a fix for that right now, as well as for the UnicodeDecodeError.
I still recommend the subnet matcher though