Skip to content

nodegroup ext_pillar handles nodegroups differently than targeting when using yaml list of minions #55146

Description

@jeff350

Description of Issue

I was able to identify a bug in how the nodegroup ext_pillar handles parsing of nodegreoups so that there are inconsistencies in group membership between a pillar.get nodegroups and targeting with -N when the nodegroup is defined as a yaml list.

The core of this issue appears to be how the compound match in the nodegroup ext_pillar handles a minion that has not had it's key accepted on the master when the nodegroup is defined as a yaml list. In the case where a minion is defined in the nodegroup yaml but has not had it's key accepted an empty list is always returned from pillar.get nodegroups when it should return the list of hosts that it does know about.

Setup

  1. set up a salt master and 2 salt minions named salt-minion-01 and salt-minion-02 and accept the kets
  2. add this file to the /etc/salt/master.d/nodegroup.conf
ext_pillar:
  - nodegroups:
      pillar_name: 'nodegroups'
nodegroups:
  minions:
    - salt-minion-01
    - salt-minion-02
    - salt-minion-03
  group1: 'L@salt-minion-01'
  group2: 'L@salt-minion-02'
  1. restart the salt-master for the config to be reloaded.
  2. run sudo salt '*' saltutil.sync_all

At this point the system is fully setup to replicate the bug.

Steps to Reproduce Issue

  1. run sudo salt -N minions test.ping this will return:
salt-minion-01:
    True
salt-minion-02:
    True

This shows that both salt minions are in the minions group as defined in the above config file.

  1. run sudo salt '*' pillar.get nodegroups this will return:
salt-minion-01:
    - group1
salt-minion-02:
    - group2

See that the pillar.get nodegroups does not show that the minions are not in the minions nodegroup this is because in line https://github.com/saltstack/salt/blob/develop/salt/pillar/nodegroups.py#L68 match for the minions nodegroup is being evaluated to [] instead of ['salt-minion-01', 'salt-minion-02']

A workaround for this issue is to define the nodegroups as defined below but it makes the config files a lot more complex

nodegroups:
  minions:
    - salt-minion-01
    - 'or'
    - salt-minion-02
    - 'or'
    - salt-minion-03
  group1: 'L@salt-minion-01'
  group2: 'L@salt-minion-02'

another solution is to use the L@ targeting where it will also return correctly as seen below

nodegroups:
  minions:
    - 'L@salt-minion-01,salt-minion-02,salt-minion-03'
  group1: 'L@salt-minion-01'
  group2: 'L@salt-minion-02'

In this case sudo salt '*' pillar.get nodegroups will show all minions in the minions group as expected.

salt-minion-01:
    - minions
    - group1
salt-minion-02:
    - minions
    - group2

Related Docs

Versions Report

Salt Version:
Salt: 2019.2.2

Dependency Versions:
cffi: Not Installed
cherrypy: Not Installed
dateutil: 2.5.3
docker-py: Not Installed
gitdb: 2.0.0
gitpython: 2.1.1
ioflo: Not Installed
Jinja2: 2.9.4
libgit2: Not Installed
libnacl: Not Installed
M2Crypto: Not Installed
Mako: Not Installed
msgpack-pure: Not Installed
msgpack-python: 0.4.8
mysql-python: Not Installed
pycparser: Not Installed
pycrypto: 2.6.1
pycryptodome: Not Installed
pygit2: Not Installed
Python: 2.7.13 (default, Sep 26 2018, 18:42:22)
python-gnupg: Not Installed
PyYAML: 3.12
PyZMQ: 16.0.2
RAET: Not Installed
smmap: 2.0.1
timelib: Not Installed
Tornado: 4.4.3
ZMQ: 4.2.1

System Versions:
dist: debian 9.11
locale: UTF-8
machine: x86_64
release: 4.9.0-11-amd64
system: Linux
version: debian 9.11

Metadata

Metadata

Assignees

No one assigned

    Labels

    ConfirmedSalt engineer has confirmed bug/feature - often including a MCVEbugbroken, incorrect, or confusing behaviorseverity-medium3rd level, incorrect or bad functionality, confusing and lacks a work around

    Type

    No type

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions