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

[BUG] roster_defaults does not apply to targets absent from roster #58440

Open
satwell opened this issue Sep 12, 2020 · 1 comment
Open

[BUG] roster_defaults does not apply to targets absent from roster #58440

satwell opened this issue Sep 12, 2020 · 1 comment
Labels
Bug broken, incorrect, or confusing behavior severity-medium 3rd level, incorrect or bad functionality, confusing and lacks a work around
Milestone

Comments

@satwell
Copy link

satwell commented Sep 12, 2020

Description
The roster_defaults key in the master config lets you set default values for targets. However, these defaults only get applied to targets that are in the roster, and not targets that are not in the roster. This is a bit confusing, because salt-ssh works just fine otherwise if you provide a target that is an explicit hostname.

Setup
This is easiest to demonstrate with an example where roster_defaults sets the port to something non-default that breaks. And two hosts listed and unlisted, only the first of which is explicitly listed in the roster.

roster

listed: {}

master

roster_defaults:
  port: 9999

Steps to Reproduce the behavior

  1. salt-ssh listed test.ping fails with an error, as expected (because nothing is listening on port 9999):
listed:
    ssh: connect to host listed port 9999: Connection refused
  1. salt-ssh unlisted test.ping does not fail, it works just fine:
unlisted.example.com:
    True

Expected behavior
I would expect the unlisted target to apply the port setting from roster_defaults and fail the same way as the listed target.

Versions Report

salt --versions-report (Provided by running salt --versions-report. Please also mention any differences in master/minion versions.)
Salt Version:
           Salt: 3001.1

Dependency Versions:
           cffi: 1.14.2
       cherrypy: Not Installed
       dateutil: 2.8.1
      docker-py: 4.1.0
          gitdb: Not Installed
      gitpython: Not Installed
         Jinja2: 2.11.2
        libgit2: Not Installed
       M2Crypto: Not Installed
           Mako: 1.1.2
   msgpack-pure: Not Installed
 msgpack-python: 0.6.2
   mysql-python: Not Installed
      pycparser: 2.20
       pycrypto: Not Installed
   pycryptodome: 3.9.7
         pygit2: Not Installed
         Python: 3.8.5 (default, Aug  2 2020, 15:09:07)
   python-gnupg: Not Installed
         PyYAML: 5.3.1
          PyZMQ: 19.0.2
          smmap: Not Installed
        timelib: Not Installed
        Tornado: 4.5.3
            ZMQ: 4.3.2

System Versions:
           dist: debian testing bullseye
         locale: utf-8
        machine: x86_64
        release: 5.7.0-3-amd64
         system: Linux
        version: Debian GNU/Linux testing bullseye
@satwell satwell added the Bug broken, incorrect, or confusing behavior label Sep 12, 2020
@sagetherage sagetherage assigned Ch3LL and unassigned s0undt3ch Oct 1, 2020
@Ch3LL
Copy link
Contributor

Ch3LL commented Oct 1, 2020

thanks, will need to get this fixed up :)

@Ch3LL Ch3LL added severity-medium 3rd level, incorrect or bad functionality, confusing and lacks a work around and removed needs-triage labels Oct 1, 2020
@Ch3LL Ch3LL added this to the Approved milestone Oct 1, 2020
@dwoz dwoz unassigned Ch3LL Jul 29, 2024
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-medium 3rd level, incorrect or bad functionality, confusing and lacks a work around
Projects
None yet
Development

No branches or pull requests

4 participants