Pillar targeting broken

felskrone commented 4 years ago

Describe the bug A Minion cant be targeted by using pillars.

Steps To Reproduce A Minion has the role "core" assigned.

# salt-sproxy cr-edge* pillar.get role
cr-edge01.mydomain.com:
    core

But it cant be targeted using -I parameter of salt-sproxy.

# salt-sproxy --preview-target -I "role:core"
No devices matched your target. Please review your tgt / tgt_type arguments, or the Roster data source

# salt-sproxy -I "role:core" test.ping
No devices matched your target. Please review your tgt / tgt_type arguments, or the Roster data source

Expected behavior The minion responds with "True".

Versions Report

# salt-sproxy -V
Salt Version:
           Salt: 3001.1
    Salt SProxy: 2020.7.0

Dependency Versions:
        Ansible: Not Installed
           cffi: 1.14.2
       dateutil: 2.7.3
      docker-py: Not Installed
          gitdb: 2.0.5
      gitpython: 2.1.11
         Jinja2: 2.10
     junos-eznc: 2.5.3
       jxmlease: Not Installed
        libgit2: 0.27.7
       M2Crypto: Not Installed
           Mako: Not Installed
   msgpack-pure: Not Installed
 msgpack-python: 0.5.6
         NAPALM: 3.1.0
       ncclient: 0.6.9
        Netmiko: 3.2.0
       paramiko: 2.7.2
      pycparser: 2.19
       pycrypto: 2.6.1
   pycryptodome: 3.6.1
         pyeapi: 0.8.3
         pygit2: 0.27.4
       PyNetBox: Not Installed
          PyNSO: Not Installed
         Python: 3.7.3 (default, Jul 25 2020, 13:03:44)
   python-gnupg: Not Installed
         PyYAML: 3.13
          PyZMQ: 17.1.2
            scp: 0.13.2
          smmap: 2.0.5
        textfsm: 1.1.0
        timelib: Not Installed
        Tornado: 4.5.3
            ZMQ: 4.3.1

System Versions:
           dist: debian 10 buster
         locale: UTF-8
        machine: x86_64
        release: 4.19.0-10-amd64
         system: Linux
        version: Debian GNU/Linux 10 buster

Additional context Pillar targeting is also not mentioned here: https://salt-sproxy.readthedocs.io/en/latest/targeting.html

But its part of the "salt-proxy -h" help. Is it generally supported?

mirceaulinic commented 4 years ago

Hi @felskrone. Thanks for reporting this.

Could you check if the following works: salt-sproxy --preview-target -C "I@role:core"? And yes, -I should be supported on 2020.7.0 (it was only added in a more recent version, and I probably forgot to add it to https://salt-sproxy.readthedocs.io/en/latest/targeting.html).

mirceaulinic commented 4 years ago

Two more questions @felskrone:

Is cr-edge01.mydomain.com a running Proxy Minion, or a device managed through purely sproxy?
Do you use any Roster?

felskrone commented 4 years ago

The command does not work.

# salt-sproxy --preview-target -C "I@role:core"
No devices matched your target. Please review your tgt / tgt_type arguments, or the Roster data source

Im using salt-sproxy only with the following roster.

root@salt-gbone:~# cat /etc/salt/roster
cr-edge02.mydomain.com:
  grains:
    test: no
cr-edge01.mydomain.com:
  grains:
    test: no

I had to specify the grains-section to get "salt-sproxy -G" working. But thats a different topic, just clarifying why its in there :)

felskrone commented 4 years ago

I you give me a good starting point on how to debug this further, i can take a look myself. Im pretty familiar with the salt-code base, just not the pillar stuff rendering.

mirceaulinic commented 4 years ago

Hey @felskrone. Sorry for being late to this. One more thing to confirm: could you run the following, in this order, for me please:

salt-sproxy --preview-target -C "I@role:core" --invasive-targeting
salt-sproxy --preview-target -C "I@role:core"
salt-sproxy \* test.ping --cache-grains --cache-pillar (can be any function, not just test.ping), followed by salt-sproxy --preview-target -C "I@role:core".

With this information, I think I'll have a better idea what's the root issue.

mirceaulinic commented 4 years ago

I think you should be good if you execute with --cache-pillar (and --cache-grains). With https://github.com/mirceaulinic/salt-sproxy/pull/173 I'm defaulting these to True so should maybe help simplifying the usage.

felskrone commented 4 years ago

Here we go.

1. 
# salt-sproxy --preview-target -C "I@role:core" --invasive-targeting
- cr-edge02.mydomain.com
- cr-edge01.mydomain.com

2. 
# salt-sproxy --preview-target -C "I@role:core"
- cr-edge01.mydomain.com

3. 
# salt-sproxy \* test.ping --cache-grains --cache-pillar
cr-edge02.mydomain.com:
    True
 cr-edge01.mydomain.com:
    True

4. 
# salt-sproxy --preview-target -C "I@role:core"
-  cr-edge01.mydomain.com

This looks better, but not quite right.

Should not return both minions, only cr-edge01 has "role: core" set.
Looks good.
Looks good.
Looks good.

But during testing this, i noticed that adding "role: core" to cr-edge02 did not reflect onto this commands. The output did not change. I had to manually remove cr-edge02's cache dir (/var/cache/salt/master/minions/cr-edge02.mydomain.com) to have it recreated with a "test.ping" to be able to use / see the newly added role.

mirceaulinic commented 4 years ago

Thanks for confirming.

But during testing this, i noticed that adding "role: core" to cr-edge02 did not reflect onto this commands. The output did not change. I had to manually remove cr-edge02's cache dir (/var/cache/salt/master/minions/cr-edge02.mydomain.com) to have it recreated with a "test.ping" to be able to use / see the newly added role.

Yes, this is one of the caveats of not running active Minions, am not sure if there's a way to work around that. Open to suggestions though. You don't need to manually remove the cache, just running any command with --cache-grains --cache-pillar before targeting -I (in order to refresh the cache) should do it though.

Should not return both minions, only cr-edge01 has "role: core" set.

This one, however, is a bug probably. I've also noticed some strange behaviour sometimes with --invasive-targeting, I'll take another look.

syntax-terr0r commented 4 years ago

Hi there,

sorry to hijack this thread but I have noticed the same behavior when adding or removing pillars:

But during testing this, i noticed that adding "role: core" to cr-edge02 did not reflect onto this commands. The output did not change. I had to manually remove cr-edge02's cache dir (/var/cache/salt/master/minions/cr-edge02.mydomain.com) to have it recreated with a "test.ping" to be able to use / see the newly added role.

Here is an example: After creating a simple pillar file...

# cat /srv/pillar/shared/test.sls
config:
  foobar: true

... and assigning it to the test host...

# cat /srv/pillar/top.sls
base:
  '*':
    - 'shared.general'
  'cr-testing01.mydomain.com':
    - shared.test

... the data is not available with pillar.get

# salt-sproxy cr-testing* pillar.get config:foobar
cr-testing01.mydomain.com:

# salt-sproxy cr-testing* pillar.items
cr-testing01.mydomain.com:
    ----------
    config:
        ----------
        foobar:
            True

It is available in pillar.items however.

Running a command with --cache-grains --cache-pillar does not change the situation:

# salt-sproxy cr-testing* test.ping --cache-grains --cache-pillar
cr-testing01.mydomain.com:
    True

# salt-sproxy cr-testing* pillar.get config:foobar
cr-testing01.mydomain.com:

After removing the cache the data is available.

# rm -r /var/cache/salt/master/minions/cr-testing01.mydomain.com/
# salt-sproxy cr-testing* pillar.get config:foobar
cr-testing01.mydomain.com:
   True

The same applies when removing pillar data as well.

biwhite commented 4 years ago

I see this also. --cache-{pillar,grains}, add an item into the pillar and nothing I do seems to ever refresh that cache/pillar with the new item. This included trying to force refresh the caches, with --cache-grains --cache-pillar again. This did not repopulate with the new information. Also deleting purely the pillar.p/grains.p files and force refreshing still didn't. There was also a data.p one level higher. Deleting the node's folder entirely and then --cache-grains --cache-pillar did the trick for re-populating and saving correctly.

Delete the salt cache folder for this node and re-cache with a test.ping and it populates the new files correctly, which then lets me target using the new pillar item

mirceaulinic commented 4 years ago

@biwhite @syntax-terr0r could you confirm what Salt versions are you running (a salt-sproxy -V would do it)?

Also deleting purely the pillar.p/grains.p files and force refreshing still didn't. There was also a data.p one level higher.

I don't think there should also be both pillar.p + grains.p and data.p - sounds like a Salt bug... Out of curiosity, was either of those updated on --cache-pillar? I'll try to reproduce it myself too, and even if it might be an upstream bug, I think we may be able to work around that. Thanks for reports, folks!

syntax-terr0r commented 4 years ago

This is the version I am running:

Salt Version:
           Salt: 3001.1
    Salt SProxy: 2020.7.0

Dependency Versions:
        Ansible: Not Installed
           cffi: 1.14.2
       dateutil: 2.7.3
      docker-py: Not Installed
          gitdb: 2.0.5
      gitpython: 2.1.11
         Jinja2: 2.10
     junos-eznc: 2.5.3
       jxmlease: Not Installed
        libgit2: 0.27.7
       M2Crypto: Not Installed
           Mako: Not Installed
   msgpack-pure: Not Installed
 msgpack-python: 0.5.6
         NAPALM: 3.1.0
       ncclient: 0.6.9
        Netmiko: 3.2.0
       paramiko: 2.7.2
      pycparser: 2.19
       pycrypto: 2.6.1
   pycryptodome: 3.6.1
         pyeapi: 0.8.3
         pygit2: 0.27.4
       PyNetBox: Not Installed
          PyNSO: Not Installed
         Python: 3.7.3 (default, Jul 25 2020, 13:03:44)
   python-gnupg: Not Installed
         PyYAML: 3.13
          PyZMQ: 17.1.2
            scp: 0.13.2
          smmap: 2.0.5
        textfsm: 1.1.0
        timelib: Not Installed
        Tornado: 4.5.3
            ZMQ: 4.3.1

System Versions:
           dist: debian 10 buster
         locale: utf-8
        machine: x86_64
        release: 4.19.0-10-amd64
         system: Linux
        version: Debian GNU/Linux 10 buster

I don't think there should also be both pillar.p + grains.p and data.p - sounds like a Salt bug...

Just as an FYI, there was/is no data.p in my cache

# tree /var/cache/salt/master/minions/cr-testing01.mydomain.com/
/var/cache/salt/master/minions/cr-testing01.mydomain.com/
`-- data
    |-- grains.p
    `-- pillar.p

mirceaulinic commented 4 years ago

@syntax-terr0r I can't reproduce your pillar.get issue

root@01d3e8cd5f03:/# salt-sproxy cr-testing01.mydomain.com pillar.items
cr-testing01.mydomain.com:
    ----------
    config:
        ----------
        foobar:
            True
    foo:
        bar
    proxy:
        ----------
root@01d3e8cd5f03:/# salt-sproxy cr-testing01.mydomain.com pillar.get config:foobar
cr-testing01.mydomain.com:
    True

root@01d3e8cd5f03:/# tree /srv/salt/
/srv/salt/
└── pillar
    ├── shared
    │   ├── global.sls
    │   └── test.sls
    └── top.sls

2 directories, 3 files
root@01d3e8cd5f03:/# cat /srv/salt/pillar/top.sls 
base:
  '*':
    - shared.global
  'cr-testing01.mydomain.com':
    - shared.test
root@01d3e8cd5f03:/# cat /srv/salt/pillar/shared/test.sls 
config:
  foobar: true
root@01d3e8cd5f03:/# cat /srv/salt/pillar/shared/global.sls 
foo: bar
root@01d3e8cd5f03:/# cat /etc/salt/master 
pillar_roots:
  base:
    - /srv/salt/pillar

file_roots:
  base:
    - /srv/salt/

proxy:
  proxytype: dummy

roster: file
root@01d3e8cd5f03:/# cat /etc/salt/roster 
cr-testing01.mydomain.com: {}
root@01d3e8cd5f03:/#

syntax-terr0r commented 4 years ago

That is very interesting.

I just ran the test again with a dummy to make sure that it wasn't a fluke the first time around:

# cat /etc/salt/roster
[...]
minion1: {}

root@salt-gbone:~# cat /srv/pillar/dummy.sls
proxy:
  proxytype: dummy

root@salt-gbone:~# cat /srv/pillar/shared/test.sls
config:
  foobar: true
root@salt-gbone:~# cat /srv/pillar/shared/global.sls
foo:
  bar

created a fresh top.sls with just the dummy, but no shared.test pillar yet

root@salt-gbone:~# cat /srv/pillar/top.sls
base:
  '*':
     - shared.global
  minion1:
    - dummy

Making sure the dummy works and is cached:

root@salt-gbone:~# salt-sproxy minion1 test.ping
minion1:
    True

root@salt-gbone:~# tree /var/cache/salt/master/minions/minion1/
/var/cache/salt/master/minions/minion1/
`-- data
    |-- grains.p
    `-- pillar.p

1 directory, 2 files

pillar.items now shows:

root@salt-gbone:~# salt-sproxy minion1 pillar.items
minion1:
    ----------
    foo:
        bar
    proxy:
        ----------
        proxytype:
            dummy

Adding shared.test now:

root@salt-gbone:~# cat /srv/pillar/top.sls
base:
  '*':
     - shared.global
  minion1:
    - dummy
    - shared.test

result:

root@salt-gbone:~# salt-sproxy minion1 pillar.items
minion1:
    ----------
    config:
        ----------
        foobar:
            True
    foo:
        bar
    proxy:
        ----------
        proxytype:
            dummy

root@salt-gbone:~# salt-sproxy minion1 pillar.get config
minion1:
root@salt-gbone:~# salt-sproxy minion1 pillar.get config:foobar
minion1:

tried updating the cache, still no dice:

root@salt-gbone:~# salt-sproxy minion1 test.ping --cache-pillar
minion1:
    True

root@salt-gbone:~# salt-sproxy minion1 pillar.get config:foobar
minion1:

only after deleting the cache does it work

root@salt-gbone:~# rm -r /var/cache/salt/master/minions/minion1/

root@salt-gbone:~# salt-sproxy minion1 pillar.get config:foobar
minion1:
    True

Just to make sure: Did you get the minion cached before adding shared.test in your test? It works as expected if I add shared.test from the start before the minion is cached.

mirceaulinic commented 4 years ago

Is anyone able to test #178 and confirm it fixes the issues you're all seeing? Cheers.

syntax-terr0r commented 4 years ago

That appears to have done it.

Added another test pillar:

root@salt-gbone:~# cat /srv/pillar/shared/test2.sls
config:
  fixed: true

root@salt-gbone:~# cat /srv/pillar/top.sls
base:
  '*':
    - shared.global
  minion1:
    - dummy
    - shared.test
    - shared.test2

and the new data shows up without having to delete the cache:

root@salt-gbone:~# salt-sproxy minion1 pillar.items
minion1:
    ----------
    config:
        ----------
        fixed:
            True
        foobar:
            True
    foo:
        bar
    proxy:
        ----------
        proxytype:
            dummy

root@salt-gbone:~# salt-sproxy minion1 pillar.get config:fixed
minion1:
    True

syntax-terr0r commented 4 years ago

Unfortunately I have noticed another issue since the fix in #178 I'm not 100% sure if it's only happening since but it might be related. See below:

I have a minion with the following grains:

# salt-sproxy cr-testing* grains.get id
cr-testing01.lab1:
    cr-testing01.lab1

# salt-sproxy cr-testing* grains.get model
cr-testing01.lab1:
    VMX

However it seems that not all grain data is correctly processed and available in the sls files

adding another test pillar:

# cat /srv/pillar/shared/test.sls
foo: {{ grains.get('id') }}
bar: {{ grains.get('model') }}

results in:

# salt-sproxy cr-testing* pillar.get foo
cr-testing01.lab1:
    cr-testing01.lab1

# salt-sproxy cr-testing* pillar.get bar
cr-testing01.lab1:
    None

The grains data for the model is not accessible/gone. When accessing the variable directly with grains['model'], rendering the sls fails with the following output:

# salt-sproxy cr-testing* pillar.get bar
[ERROR   ] Rendering exception occurred
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/salt/utils/templates.py", line 400, in render_jinja_tmpl
    output = template.render(**decoded_context)
  File "/usr/lib/python3/dist-packages/jinja2/asyncsupport.py", line 76, in render
    return original_render(self, *args, **kwargs)
  File "/usr/lib/python3/dist-packages/jinja2/environment.py", line 1008, in render
    return self.environment.handle_exception(exc_info, True)
  File "/usr/lib/python3/dist-packages/jinja2/environment.py", line 780, in handle_exception
    reraise(exc_type, exc_value, tb)
  File "/usr/lib/python3/dist-packages/jinja2/_compat.py", line 37, in reraise
    raise value.with_traceback(tb)
  File "<template>", line 2, in top-level template code
jinja2.exceptions.UndefinedError: 'salt.utils.odict.OrderedDict object' has no attribute 'model'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/salt/utils/templates.py", line 166, in render_tmpl
    output = render_str(tmplstr, context, tmplpath)
  File "/usr/lib/python3/dist-packages/salt/utils/templates.py", line 407, in render_jinja_tmpl
    raise SaltRenderError("Jinja variable {0}{1}".format(exc, out), buf=tmplstr)
salt.exceptions.SaltRenderError: Jinja variable 'salt.utils.odict.OrderedDict object' has no attribute 'model'
[CRITICAL] Rendering SLS 'shared.test' failed, render error:
Jinja variable 'salt.utils.odict.OrderedDict object' has no attribute 'model'
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/salt/utils/templates.py", line 400, in render_jinja_tmpl
    output = template.render(**decoded_context)
  File "/usr/lib/python3/dist-packages/jinja2/asyncsupport.py", line 76, in render
    return original_render(self, *args, **kwargs)
  File "/usr/lib/python3/dist-packages/jinja2/environment.py", line 1008, in render
    return self.environment.handle_exception(exc_info, True)
  File "/usr/lib/python3/dist-packages/jinja2/environment.py", line 780, in handle_exception
    reraise(exc_type, exc_value, tb)
  File "/usr/lib/python3/dist-packages/jinja2/_compat.py", line 37, in reraise
    raise value.with_traceback(tb)
  File "<template>", line 2, in top-level template code
jinja2.exceptions.UndefinedError: 'salt.utils.odict.OrderedDict object' has no attribute 'model'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/salt/pillar/__init__.py", line 885, in render_pstate
    **defaults
  File "/usr/lib/python3/dist-packages/salt/template.py", line 106, in compile_template
    ret = render(input_data, saltenv, sls, **render_kwargs)
  File "/usr/lib/python3/dist-packages/salt/renderers/jinja.py", line 79, in render
    **kws
  File "/usr/lib/python3/dist-packages/salt/utils/templates.py", line 166, in render_tmpl
    output = render_str(tmplstr, context, tmplpath)
  File "/usr/lib/python3/dist-packages/salt/utils/templates.py", line 407, in render_jinja_tmpl
    raise SaltRenderError("Jinja variable {0}{1}".format(exc, out), buf=tmplstr)
salt.exceptions.SaltRenderError: Jinja variable 'salt.utils.odict.OrderedDict object' has no attribute 'model'
[CRITICAL] Pillar render error: Rendering SLS 'shared.test' failed. Please see master log for details.
cr-testing01.lab1:

I'm relatively sure that this worked before because I also have pillar file in my top.sls which I assign based on 'P@model:(VMX|MX960)'and that is also no longer being merged into the pillar data.

Let me know if I should rather open a new issue for this or if it's related.

mirceaulinic commented 4 years ago

I'm not 100% sure if it's only happening since but it might be related.

It'd be great if you could check and update here.

syntax-terr0r commented 4 years ago

Ok, so I reverted the patch from #178 and it is still not working. I'm not sure why it did work before (at least once) then, but at least I found a lead on why it's not working right now.

It seems that the napalm grains (salt/grains/napalm.py) are only merged into the grains dict after the pillars have been rendered:

2020-10-13 12:34:05,142 [salt.template    :127 ][DEBUG   ][14313] Rendered data from file: /srv/pillar/shared/test.sls:
[...]
2020-10-13 12:34:08,780 [salt.loaded.ext.runners.proxy:665 ][DEBUG   ][14313] Caching Grains for cr-testing01.lab1
2020-10-13 12:34:08,780 [salt.loaded.ext.runners.proxy:666 ][DEBUG   ][14313] OrderedDict([('foo', 'bar'), ('cwd', '/root'), ('ip_gw', True), ('ip4_gw', '62.138.167.49'), ('ip6_gw', False), ('dns', {'nameservers': ['80.237.128.144', '80.237.128.145', '8.8.8.8'], 'ip4_nameservers': ['80.237.128.144', '80.237.128.145', '8.8.8.8'], 'ip6_nameservers': [], 'sortlist': [], 'domain': '', 'search': ['bb.gdinf.net', 'bb.godaddy.com', 'lab.mass.systems', 'cse.mass.systems', 'mass.systems', 'intern.hosteurope.de', 'hosteurope.de'], 'options': []}), ('fqdns', []), ('machine_id', 'f6183af91209426f812aca156ae54f5a'), ('master', 'salt'), ('hwaddr_interfaces', {'lo': '00:00:00:00:00:00', 'eth0': '02:ce:0a:5d:c0:49'}), ('id', 'cr-testing01.lab1'), ('kernelparams', [('BOOT_IMAGE', '/boot/vmlinuz-4.19.0-10-amd64'), ('root', None), ('ro', None), ('quiet', None)]), ('locale_info', {}), ('num_gpus', 0), ('gpus', []), ('kernel', 'proxy'), ('nodename', 'salt-gbone.lab.mass.systems'), ('kernelrelease', 'proxy'), ('kernelversion', 'proxy'), ('cpuarch', 'x86_64'), ('osrelease', 'proxy'), ('os', 'junos'), ('os_family', 'proxy'), ('osfullname', 'proxy'), ('osarch', 'x86_64'), ('mem_total', 0), ('virtual', 'LXC'), ('ps', 'ps -efHww'), ('osrelease_info', ('proxy',)), ('osfinger', 'proxy-proxy'), ('path', '/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin'), ('systempath', ['/usr/local/sbin', '/usr/local/bin', '/usr/sbin', '/usr/bin', '/sbin', '/bin']), ('pythonexecutable', '/usr/bin/python3'), ('pythonpath', ['/usr/lib/python3/dist-packages/git/ext/gitdb', '/usr/local/bin', '/usr/lib/python37.zip', '/usr/lib/python3.7', '/usr/lib/python3.7/lib-dynload', '/usr/local/lib/python3.7/dist-packages', '/usr/lib/python3/dist-packages', '/usr/lib/python3/dist-packages/gitdb/ext/smmap']), ('pythonversion', [3, 7, 3, 'final', 0]), ('saltpath', '/usr/lib/python3/dist-packages/salt'), ('saltversion', '3001.1'), ('saltversioninfo', [3001, 1]), ('zmqversion', '4.3.1'), ('disks', []), ('ssds', ['sdb', 'sda']), ('shell', '/bin/bash'), ('username', None), ('groupname', 'root'), ('pid', 14313), ('gid', 0), ('uid', 0), ('zfs_support', False), ('zfs_feature_flags', False), ('host', 'cr-testing01.lab1'), ('hostname', 'cr-testing01.lab1'), ('interfaces', ['ge-0/0/0', 'lc-0/0/0', 'pfe-0/0/0', 'pfh-0/0/0', 'ge-0/0/1', 'ge-0/0/2', 'ge-0/0/3', 'ge-0/0/4', 'ge-0/0/5', 'ge-0/0/6', 'ge-0/0/7', 'ge-0/0/8', 'ge-0/0/9', 'cbp0', 'demux0', 'dsc', 'em1', 'esi', 'fxp0', 'gre', 'ipip', 'irb', 'jsrv', 'lo0', 'lsi', 'mtun', 'pimd', 'pime', 'pip0', 'pp0', 'rbeb', 'tap', 'vtep']), ('model', 'VMX'), ('optional_args', {'config_lock': False, 'keepalive': 5}), ('serial', 'VM5B598A6585'), ('uptime', 2505569), ('vendor', 'Juniper'), ('version', '17.4R1.16')])

I have modified the test.sls like so

# cat /srv/pillar/shared/test.sls
foo: {{ grains.get('id') }}
bar: {{ grains.get('model') }}

{% for k in grains.keys() %}
{%- do salt.log.error(k) -%}
{% endfor %}

and these are the grains keys available at SLS rendering:

# salt-sproxy cr-testing* pillar.get bar
[ERROR   ] cwd
[ERROR   ] ip_gw
[ERROR   ] ip4_gw
[ERROR   ] ip6_gw
[ERROR   ] dns
[ERROR   ] fqdns
[ERROR   ] machine_id
[ERROR   ] master
[ERROR   ] hwaddr_interfaces
[ERROR   ] id
[ERROR   ] kernelparams
[ERROR   ] locale_info
[ERROR   ] num_gpus
[ERROR   ] gpus
[ERROR   ] kernel
[ERROR   ] nodename
[ERROR   ] kernelrelease
[ERROR   ] kernelversion
[ERROR   ] cpuarch
[ERROR   ] osrelease
[ERROR   ] os
[ERROR   ] os_family
[ERROR   ] osfullname
[ERROR   ] osarch
[ERROR   ] mem_total
[ERROR   ] virtual
[ERROR   ] ps
[ERROR   ] osrelease_info
[ERROR   ] osfinger
[ERROR   ] path
[ERROR   ] systempath
[ERROR   ] pythonexecutable
[ERROR   ] pythonpath
[ERROR   ] pythonversion
[ERROR   ] saltpath
[ERROR   ] saltversion
[ERROR   ] saltversioninfo
[ERROR   ] zmqversion
[ERROR   ] disks
[ERROR   ] ssds
[ERROR   ] shell
[ERROR   ] username
[ERROR   ] groupname
[ERROR   ] pid
[ERROR   ] gid
[ERROR   ] uid
[ERROR   ] zfs_support
[ERROR   ] zfs_feature_flags
cr-testing01.lab1:
    None

As you can see it's missing the following keys

-host
-hostname
-interfaces
-model
-optional_args
-serial
-uptime
-vendor
-version

which as far as I can see are all gathered in napalm.py

But this is most likely a different issue than the one in this thread. Let me know if you want me to raise a new issue for this.

mirceaulinic commented 4 years ago

But this is most likely a different issue than the one in this thread. Let me know if you want me to raise a new issue for this.

Yes, @syntax-terr0r, that'd be a separate issue.

@biwhite @felskrone would you also be able to confirm #178 solves the initial issue?

mirceaulinic commented 4 years ago

Believe this should be fixed, but do reopen if you're still noticing the behaviour.

mirceaulinic / salt-sproxy

Pillar targeting broken #169