ENC parameters - how to access from sls/template

[mclarkson]

Hi, I have an external node classifier returning data as shown below. In sls and template files I have tried {{ vim_new_value }} and {{ vim_test_value }} but for each I get <variable> is undefined. I have also tried a suggestion from the salt newsgroup: {{ salt\['pillar.get'\]('vim_test_value') }}, also without success.

How do I access vim_new_value and vim_test_value? Is it possible?

ENC return data:

classes:
  cron:
  locale:
  logrotate:
  mysql:
  mysql.remove_test_database:
  salt:
  salt.cron:
  snmpd:
  timezone:
  vim:
  vim.vimrc:
    vim_new_value: where am i
parameters:
  vim_test_value: a test value
environment: test_0.1.1

Thanks, Mark.

[jfindlay]

Thanks for reporting this. Can you provide the output of salt --versions and also a minimal configuration to demonstrate the problem? Thanks.

[mclarkson]

# cat /etc/redhat-release 
CentOS release 6.6 (Final)
# salt --versions-report
           Salt: 2014.7.0
         Python: 2.6.6 (r266:84292, Jan 22 2014, 09:42:36)
         Jinja2: unknown
       M2Crypto: 0.20.2
 msgpack-python: 0.1.13
   msgpack-pure: Not Installed
       pycrypto: 2.0.1
        libnacl: Not Installed
         PyYAML: 3.10
          ioflo: Not Installed
          PyZMQ: 14.3.1
           RAET: Not Installed
            ZMQ: 3.2.4
           Mako: Not Installed

Um. I guess you'd need a shell script, maybe 'enc_test.sh', such as:

#!/bin/bash

cat <<EnD
classes:
  cron:
  locale:
  logrotate:
  mysql:
  mysql.remove_test_database:
  salt:
  salt.cron:
  snmpd:
  timezone:
  vim:
  vim.vimrc:
    vim_new_value: where am i
parameters:
  vim_test_value: a test value
environment: test_0.1.1
EnD

exit 0

Then 'chmod +x' the script and place in '/usr/bin/'. Add to the salt 'master' file:

master_tops:
  ext_nodes: enc_test.sh

Then reference the 'vim_new_value' and 'vim_test_value' in a state file or template. I don't know how to reference the parameters, which was partly my question, so I'm not sure how to write that part.

[mclarkson]

Blocked? Could someone at least answer whether accessing parameters should actually be possible or not? I.e. is this really a bug? or is using parameters unsupported?

[cro]

I'm struggling a little bit to understand exactly what you are expecting out of master_tops: ext_nodes... Master_tops provides a pluggable interface to replace top.sls with information from another source. The top file maps which SLS files will be made available. (see http://docs.saltstack.com/en/latest/ref/tops/all/salt.tops.ext_nodes.html#module-salt.tops.ext_nodes and http://docs.saltstack.com/en/latest/ref/states/top.html, apologies if you have already read those). In particular, the examples in those links don't look like what you have provided above.

It sounds to me like you are trying to achieve something that is better provided by another feature of Salt. Can you elaborate a little bit. I bet we can figure something out that will make more sense.

[mclarkson]

Thanks for taking a look at this issue cro. I was looking at issue #355 (Support puppet style external node classification) where it showed the test data to be used as:

[root@omniscience salt]$ cobbler-ext-nodes omniscience
classes: [webserver, edit]
parameters: {from_cobbler: 1}

That ticket also points to the Puppet documentation for the ENC, so I had hoped that the salt ENC supported Puppet ENC format. Granted, that ticket was closed in 2012.

I wanted to know if the Salt ENC supported parameters like the Puppet ENC does.

I have implemented an ENC as a replacement for top.sls and I'm planning on using an external pillar for specifying node specific data. Parameters would have been great for this, that is, it would have saved me work(!), but using external pillars looks like a good solution.

This is for a GUI project (Obdi) where I would like to specify state files, formulas, and pillar data directly to the host from the GUI rather than from code. I think an external pillar is the way to go but any feedback would be welcome.

[stale[bot]]

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.