From a discussion in IRC. Details to follow.
Example grains from a Solaris host here: http://pastebin.com/ndBq1B19
The problem, from what I can see, is that osrelease is not even being created for minions with 'SunOS' kernels. This should be able to be derived from /etc/release if present.
@thatch45 So, the relevant line in /etc/release on a Solaris box looks like so:
Solaris 10 10/09 s10x_u8wos_08a X86
I'm thinking that osrelease should be 10 10/09 in this case. What are your thoughts?
Yes, that looks right, is there a Solaris expert out there to corroborate this?
I've gotten confirmation from a couple Solaris people.
I sent a patch (derived from a git diff against 0.13.1, the version which the person who reported this issue is running in production) to the person I'm working with on this, and I'm waiting to hear back on whether it fixes the issue.
Note that this issue is not a blocker, as it just results in a failure while running salt.modules.yumpkg.__virtual__(), which does not really hurt a Solaris host. Fixing it will serve to clean up log errors on Solaris minions, though.
Still waiting on confirmation from the guy I've been working with, but I tested this logic on the example /etc/release he sent me and have confirmed that it is working. I submitted a pull for this and it was just merged.
Set osrelease grain on Solaris hosts
This fixes #4321.
Finally able to verify:
$ sudo salt some-solaris-host grains.items |grep osrelease
osrelease: 10 10/09
woot, thanks for following up!