Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jinja condition is not being evaluated correctly in salt-ssh minion #56030

Open
admd opened this issue Jan 30, 2020 · 7 comments
Open

Jinja condition is not being evaluated correctly in salt-ssh minion #56030

admd opened this issue Jan 30, 2020 · 7 comments
Labels
Bug broken, incorrect, or confusing behavior severity-low 4th level, cosemtic problems, work around exists
Projects
Milestone

Comments

@admd
Copy link
Contributor

admd commented Jan 30, 2020

Description of Issue

I need to check if salt module exist before executing it. So I have a Jinja condition in statefile but it is not working on salt-ssh minion.

Setup

{% if 'network.fqdns' in salt %}
fqdns:
  module.run:
    - name: network.fqdns
{% endif%}

Above excerpt correctly returns nothing when executed on a regular minion and network.fqdns module is not available. But when executed on a salt-ssh minion, it returns.

   module_|-fqdns_|-network.fqdns_|-run": {
            "__id__": "fqdns",
            "__run_num__": 10,
            "changes": {},
            "comment": "Module function network.fqdns is not available",
            "duration": 343.473,
            "name": "network.fqdns",
            "result": false,
            "start_time": "13:14:03.907709"
        }

which is not what I expect.

Steps to Reproduce Issue

Execute a state with a condition like above, once on a regular minion and once on salt-ssh minion. Regular minion will return nothing in case module is not there while salt-ssh minions will return the result as mentioned above.

Versions Report

Salt Version:
           Salt: 2019.2.0
 
Dependency Versions:
           cffi: 1.5.2
       cherrypy: Not Installed
       dateutil: Not Installed
      docker-py: Not Installed
          gitdb: Not Installed
      gitpython: Not Installed
          ioflo: Not Installed
         Jinja2: 2.8
        libgit2: Not Installed
        libnacl: Not Installed
       M2Crypto: Not Installed
           Mako: Not Installed
   msgpack-pure: Not Installed
 msgpack-python: 0.4.6
   mysql-python: Not Installed
      pycparser: 2.10
       pycrypto: 2.6.1
   pycryptodome: Not Installed
         pygit2: Not Installed
         Python: 2.7.13 (default, Jan 11 2017, 10:56:06) [GCC]
   python-gnupg: Not Installed
         PyYAML: 3.10
          PyZMQ: 14.0.0
           RAET: Not Installed
          smmap: Not Installed
        timelib: Not Installed
        Tornado: 4.2.1
            ZMQ: 4.0.4
 
System Versions:
           dist: SuSE 12 x86_64
         locale: UTF-8
        machine: x86_64
        release: 4.4.21-69-default
         system: Linux
        version: SUSE Linux Enterprise Server  12 x86_64
@Akm0d Akm0d added Core relates to code central or existential to Salt Salt-SSH labels Feb 7, 2020
@Akm0d Akm0d added this to the Approved milestone Feb 7, 2020
@Akm0d Akm0d added this to Considering in Sodium Feb 7, 2020
@stale
Copy link

stale bot commented Mar 8, 2020

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

If this issue is closed prematurely, please leave a comment and we will gladly reopen the issue.

@stale stale bot added the stale label Mar 8, 2020
@stale stale bot closed this as completed Mar 16, 2020
Sodium automation moved this from Considering to Done Mar 16, 2020
@admd
Copy link
Contributor Author

admd commented Mar 16, 2020

This problem still exists and I would appreciate it if someone from the salt team could provide some information about the possible fix.

@max-arnold
Copy link
Contributor

max-arnold commented Mar 16, 2020

I'm also interested in a fix. The root of the problem seems to be here:

https://github.com/saltstack/salt/blob/master/salt/client/ssh/wrapper/__init__.py#L66-L99

According to Python docs, __getitem__ should raise KeyError if the key is not found. This is not the case. The method returns None and this somehow evaluates as True in Jinja.

However, adding raise KeyError(cmd) at the end fails with KeyError: 'test.opts_pkg' that is used by salt-ssh earlier.

@Ch3LL Maybe you can shed some light on this issue (and also reopen it)?

@max-arnold
Copy link
Contributor

@admd The workaround is to use the following syntax:

{% if salt.get('network.fqdns', None) %}

@brejoc
Copy link
Contributor

brejoc commented Mar 17, 2020

Bad bot!

@Ch3LL Ch3LL reopened this Mar 25, 2020
Sodium automation moved this from Done to In progress Mar 25, 2020
@stale
Copy link

stale bot commented Mar 25, 2020

Thank you for updating this issue. It is no longer marked as stale.

@stale stale bot removed the stale label Mar 25, 2020
@Ch3LL Ch3LL added Bug broken, incorrect, or confusing behavior team-ssh severity-low 4th level, cosemtic problems, work around exists and removed Core relates to code central or existential to Salt Salt-SSH labels Mar 25, 2020
@Ch3LL Ch3LL self-assigned this Mar 25, 2020
@Ch3LL
Copy link
Contributor

Ch3LL commented Mar 25, 2020

ive added this issue to my backlog to take a look at, time permitting

@sagetherage sagetherage removed this from In progress in Sodium May 22, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug broken, incorrect, or confusing behavior severity-low 4th level, cosemtic problems, work around exists
Projects
No open projects
Magnesium
  
Awaiting triage
Development

No branches or pull requests

6 participants