saltstack / saltstack/salt

[BUG] failhard:True doesn't work properly when `test=true` is used

Open
#64,906 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

bug Core
Dominant language
Python
Stars
15.7k
Forks
5.6k
Avg merge
2d 44m
Merged PRs (30d)
80

Description

Description
I am using jinja section of code to test some stuff [network.connect and so..] and based on that I am printing some error output using test.fail_without_changes module. If I am missing some conenctivity I want to stop execution of whole state/formula and therefor I am using failhard: True. Problem is when I do "dry" run and use test=true argument. In that case is jinja section of code executed anyway and Salt already knows that there is state which have option failhard: True and which will end with failure.. and yet.. it prints also states which clearly wouldn't be executed because of previous fail w. failhard: True..

Setup

root@ubuntu22-3006:~# cat /srv/salt/production/test_fail/init.sls

test_fail:
  test.fail_without_changes:
    - failhard: True

this_state_shouldn't_be_shown_if_previous_failed_hard:
  test.succeed_without_changes

Please be as specific as possible and give set-up details.

  • on-prem machine
  • VM - VirtualBox (Virtualbox, KVM, etc. please specify)
  • VM running on a cloud service, please be explicit and add details
  • container (Kubernetes, Docker, containerd, etc. please specify)
  • or a combination, please be explicit
  • jails if it is FreeBSD
  • classic packaging
  • onedir packaging
  • used bootstrap to install

This was tested on classic packaging salt master/minion 3004.2 and also on onedir packaging 3006.1. It was also tested on VirtualBox and in on-prem machine.. Results were consistent..

Steps to Reproduce the behavior
dry run:

root@ubuntu22-3006:~# salt  'ubuntu22-3006' state.apply test_fail test=true
ubuntu22-3006:
----------
          ID: test_fail
    Function: test.fail_without_changes
      Result: False
     Comment: If we weren't testing, this would be a failure!
     Started: 08:55:14.955886
    Duration: 1.245 ms
     Changes:
----------
          ID: this_state_shouldn't_be_shown_if_previous_failed_hard
    Function: test.succeed_without_changes
      Result: True
     Comment: Success!
     Started: 08:55:14.957256
    Duration: 0.344 ms
     Changes:

Summary for ubuntu22-3006
------------
Succeeded: 1
Failed:    1
------------
Total states run:     2
Total run time:   1.589 ms

without test=true:

root@ubuntu22-3006:~# salt  'ubuntu22-3006' state.apply test_fail
ubuntu22-3006:
----------
          ID: test_fail
    Function: test.fail_without_changes
      Result: False
     Comment: Failure!
     Started: 08:55:29.267413
    Duration: 1.208 ms
     Changes:

Summary for ubuntu22-3006
------------
Succeeded: 0
Failed:    1
------------
Total states run:     1
Total run time:   1.208 ms
ERROR: Minions returned with non-zero exit code

Expected behavior
I would expect that during "dry" run is printed only output till first state which will obviously fail and have failhard: True property defined:

root@ubuntu22-3006:~# salt  'ubuntu22-3006' state.apply test_fail test=true
ubuntu22-3006:
----------
          ID: test_fail
    Function: test.fail_without_changes
      Result: False
     Comment: If we weren't testing, this would be a failure!
     Started: 08:55:14.955886
    Duration: 1.245 ms
     Changes:

Summary for ubuntu22-3006
------------
Succeeded: 0
Failed:    1
------------
Total states run:     1
Total run time:   1.589 ms
ERROR: Minions returned with non-zero exit code

Screenshots
I think that previous outputs as self-explanatory.

Versions Report

salt --versions-report (Provided by running salt --versions-report. Please also mention any differences in master/minion versions.)
root@ubuntu22-3006:~# salt --versions-report
Salt Version:
          Salt: 3006.1

Python Version:
        Python: 3.10.11 (main, May  5 2023, 02:31:54) [GCC 11.2.0]

Dependency Versions:
          cffi: 1.14.6
      cherrypy: unknown
      dateutil: 2.8.1
     docker-py: Not Installed
         gitdb: Not Installed
     gitpython: Not Installed
        Jinja2: 3.1.2
       libgit2: Not Installed
  looseversion: 1.0.2
      M2Crypto: Not Installed
          Mako: Not Installed
       msgpack: 1.0.2
  msgpack-pure: Not Installed
  mysql-python: Not Installed
     packaging: 22.0
     pycparser: 2.21
      pycrypto: Not Installed
  pycryptodome: 3.9.8
        pygit2: Not Installed
  python-gnupg: 0.4.8
        PyYAML: 5.4.1
         PyZMQ: 23.2.0
        relenv: 0.12.3
         smmap: Not Installed
       timelib: 0.2.4
       Tornado: 4.5.3
           ZMQ: 4.3.4

System Versions:
          dist: ubuntu 22.04.2 jammy
        locale: utf-8
       machine: x86_64
       release: 5.15.0-76-generic
        system: Linux
       version: Ubuntu 22.04.2 jammy

Additional context
Add any other context about the problem here.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Reproduce the issue with /srv/salt/production/test_fail/init.sls and the supplied salt state.apply test_fail test=true command, then compare it with the non-test run. Trace the state application path handling test=true and failhard; done means the dry run reports only the failing state and stops subsequent state execution.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
devops, infrastructure
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
42/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.