Pillar targeting broken #169

felskrone · 2020-09-08T07:35:08Z

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?

The text was updated successfully, but these errors were encountered:

mirceaulinic · 2020-09-09T10:49:48Z

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 · 2020-09-09T11:01:06Z

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 · 2020-09-10T14:13:39Z

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 · 2020-09-10T14:14:51Z

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 · 2020-09-25T10:35:45Z

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 · 2020-09-29T11:36:14Z

I think you should be good if you execute with --cache-pillar (and --cache-grains). With #173 I'm defaulting these to True so should maybe help simplifying the usage.

felskrone · 2020-09-29T18:05:38Z

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 · 2020-10-01T10:49:41Z

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 · 2020-10-02T12:32:27Z

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 · 2020-10-06T09:45:24Z

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 · 2020-10-09T09:16:56Z

@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 · 2020-10-09T09:23:29Z

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 · 2020-10-09T11:35:49Z

@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 · 2020-10-09T12:07:09Z

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 · 2020-10-09T12:43:21Z

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

syntax-terr0r · 2020-10-09T13:10:54Z

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 · 2020-10-12T13:30:35Z

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 · 2020-10-12T19:08:13Z

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 · 2020-10-13T12:32:05Z

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 · 2020-10-14T12:41:12Z

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?

Attempt to fix the caching issues from #169

mirceaulinic · 2020-10-23T10:56:56Z

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

felskrone added bug Something isn't working pending triage labels Sep 8, 2020

mirceaulinic added this to the APPROVED milestone Sep 9, 2020

mirceaulinic added accepted and removed pending triage labels Sep 9, 2020

mirceaulinic modified the milestones: APPROVED, 2020.10.0 Sep 29, 2020

mirceaulinic added a commit that referenced this issue Oct 9, 2020

Attempt to fix the caching issues from #169

64605e2

mirceaulinic added a commit that referenced this issue Oct 23, 2020

Merge pull request #178 from mirceaulinic/pillar-tgt-b0rk

f465052

Attempt to fix the caching issues from #169

mirceaulinic closed this as completed Oct 23, 2020

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Pillar targeting broken #169

Pillar targeting broken #169

felskrone commented Sep 8, 2020 •

edited

mirceaulinic commented Sep 9, 2020

mirceaulinic commented Sep 9, 2020

felskrone commented Sep 10, 2020

felskrone commented Sep 10, 2020

mirceaulinic commented Sep 25, 2020

mirceaulinic commented Sep 29, 2020

felskrone commented Sep 29, 2020 •

edited

mirceaulinic commented Oct 1, 2020 •

edited

syntax-terr0r commented Oct 2, 2020 •

edited

biwhite commented Oct 6, 2020 •

edited

mirceaulinic commented Oct 9, 2020

syntax-terr0r commented Oct 9, 2020 •

edited

mirceaulinic commented Oct 9, 2020

syntax-terr0r commented Oct 9, 2020

mirceaulinic commented Oct 9, 2020

syntax-terr0r commented Oct 9, 2020

syntax-terr0r commented Oct 12, 2020 •

edited

mirceaulinic commented Oct 12, 2020

syntax-terr0r commented Oct 13, 2020 •

edited

mirceaulinic commented Oct 14, 2020

mirceaulinic commented Oct 23, 2020

Pillar targeting broken #169

Pillar targeting broken #169

Comments

felskrone commented Sep 8, 2020 • edited

mirceaulinic commented Sep 9, 2020

mirceaulinic commented Sep 9, 2020

felskrone commented Sep 10, 2020

felskrone commented Sep 10, 2020

mirceaulinic commented Sep 25, 2020

mirceaulinic commented Sep 29, 2020

felskrone commented Sep 29, 2020 • edited

mirceaulinic commented Oct 1, 2020 • edited

syntax-terr0r commented Oct 2, 2020 • edited

biwhite commented Oct 6, 2020 • edited

mirceaulinic commented Oct 9, 2020

syntax-terr0r commented Oct 9, 2020 • edited

mirceaulinic commented Oct 9, 2020

syntax-terr0r commented Oct 9, 2020

mirceaulinic commented Oct 9, 2020

syntax-terr0r commented Oct 9, 2020

syntax-terr0r commented Oct 12, 2020 • edited

mirceaulinic commented Oct 12, 2020

syntax-terr0r commented Oct 13, 2020 • edited

mirceaulinic commented Oct 14, 2020

mirceaulinic commented Oct 23, 2020

felskrone commented Sep 8, 2020 •

edited

felskrone commented Sep 29, 2020 •

edited

mirceaulinic commented Oct 1, 2020 •

edited

syntax-terr0r commented Oct 2, 2020 •

edited

biwhite commented Oct 6, 2020 •

edited

syntax-terr0r commented Oct 9, 2020 •

edited

syntax-terr0r commented Oct 12, 2020 •

edited

syntax-terr0r commented Oct 13, 2020 •

edited