SaltStack - map.jinja file cannot match on grain of type dictionary, am I defining grains incorrectly?
<p>I'm using a map.jinja file in a state that uses grains.filter_by, matching on a grain w/ id 'role'. This is used to dynamically set the version of Java that an application uses. I know, weird, but that's how the system I inherited works today, so I'm setting it up as such in configuration management as step 1 to making things better. The map file has no problems at all on hosts with the grain value 'role' being a single item (which I believe is a list in yaml). </p>

<p>Example of the map file:</p>

<pre><code>{% set java = salt['grains.filter_by']({
    'default': {
        'link_target': '/path/jdk1.7.0_03',
    },
    'appA': {
        'link_target': '/path/jdk1.7.0_75',
    },
    'appB': {
        'link_target': '/path/jdk1.6.0_06',
    },
},
grain='role',
default='default'
)%}
</code></pre>

<p>Grain values for host w/ a dictionary of role values, I get the error on these hosts:</p>

<pre><code> role:
    ----------
    appA:
        None
    appC:
        None
    appD:
        ----------
        someBool:
            True
        someVendor:
            microsoft
        someBool2:
            False
        someVendor2:
            apple
        type:
            delayed
</code></pre>

<p>Grain values for hosts without a dictionary for grains, no error:</p>

<pre><code>role:
    appB
</code></pre>

<p>Error:</p>

<pre><code>    Data failed to compile:
----------
    Rendering SLS 'base:java' failed: Jinja error: unhashable type: 'dict'
/var/cache/salt/minion/files/base/java/map.jinja(1):
---
{% set java = salt['grains.filter_by']({    &lt;======================
</code></pre>

<p>Now, I'm pretty sure this is because my grain value with a dictionary of role values parses into yaml differently than my grain values that are a simple key:value pair. </p>

<p>I'm new to SaltStack and YAML, so I'm likely missing something trivial here. Am I getting too complex with my grain values? Do you have a fix or recommendation on a better way to do this?</p>