Example of passing variables from state files to template files

[Kurtis vel]

Does anyone have an example of passing variables from state files to be rendered in a temple file. I'm trying to do it a bit like puppet does so puppet wise it looks something like.

class monit ($os_install='UNSET'){

    ....
    $admin = "m...@admin.com"

    file { "/etc/monitrc":
        mode    => "700",
        content => template("monit/monitrc.erb");
      
    }
  }

and the template would render the mmonit_host var something like:


 

set daemon  30           # check services at 30 second intervals
set logfile /var/log/monit.log
set alert <%= $admin => but not on {
    checksum } with reminder on 10 cycles

set mailserver localhost
set eventqueue basedir /var/monit/ slots 1000

set httpd port 2812 and
     use address  127.0.0.1 # only accept connection from eth1
     allow localhost        # allow localhost to connect to the server and
     allow admin:monit      # require user 'admin' with password 'monit'

[Thomas S Hatch]

If you are running the latest salt this should work just fine

/etc/monitrc:
  file.managed:

    - admin: m...@admin.com

    - template: jinja

    - source: salt://monit/monitrc

then in the monitrc file you use the variable with jinja:

{{admin}}

[Jeff Schroeder]

On Fri, May 11, 2012 at 2:59 PM, Thomas S Hatch <that...@gmail.com> wrote:
> If you are running the latest salt this should work just fine
>
> /etc/monitrc:
>   file.managed:
>     - admin: m...@admin.com
>     - template: jinja
>     - source: salt://monit/monitrc
>
> then in the monitrc file you use the variable with jinja:
>
> {{admin}}

Context should also do this correctly. Clint posted something online
and I stole it for an example:

/home/kojiadmin/.koji/config:
file.managed:
- source: salt://koji/files/config
- user: kojiadmin
- group: kojiadmin
- mode: 644
- template: jinja
- context:
kojiweb_url: "http://koji2.egavas.org/koji/"
kojihub_url: "http://kojihub2.egavas.org/kojihub"
kojipkg_url: "http://kojihub2.egavas.org/mnt/koji/packages"
- require:
- user: kojiadmin

That should work with a bit older salt as well as the lastest.

--
Jeff Schroeder

Don't drink and derive, alcohol and analysis don't mix.
http://www.digitalprognosis.com

[Aaron R]

Does anyone have an example of passing variables from state files to be rendered in a temple file. I'm trying to do it a bit like puppet does so puppet wise it looks something like.

Another example, is a Jinja Macro

{%- macro monitconf(name,pid) %}

/etc/monit/conf.d/{{name}}.conf:

  file:

    - managed

    - source: salt://monit/conf.d/base.conf

    - template: jinja

    - context: {

      svcname: "{{name}}",

      pidpath: "{{pid}}" }

    - require:

      - pkg: monit

{%- endmacro %} 

------------------------------------------------

usage in another sls

{% from 'monit/init.sls' import monitconf with context %}

{{ monitconf('salt-minion',"salt-minion.pid") }}

------------------------------------------------------------

And the template file

#  Monit check:  {{ svcname }}

check process {{ svcname }} with pidfile /var/run/{{ pidpath }}

    start program = "/sbin/start {{ svcname }}" with timeout 60 seconds

    stop program = "/sbin/stop {{ svcname }}" with timeout 60 seconds

    if cpu > 80% for 2 cycles then alert

    if 5 restarts within 5 cycles then timeout

[Jacob Albretsen]

On Friday, May 11, 2012 03:59:13 PM Thomas S Hatch wrote:
> If you are running the latest salt this should work just fine
>
> /etc/monitrc:
> file.managed:
> - admin: m...@admin.com
> - template: jinja
> - source: salt://monit/monitrc
>
> then in the monitrc file you use the variable with jinja:
>
> {{admin}}

Late to the party.

Just an observation, what if a keyword for the file state in the future is
"admin"? Point being someone could use a variable name that the project adds
as an option later and updating could break things. The context / default
method seems to be a safer way to guarantee something like this doesn't happen
to users for future expansions of state options.

[David Ward]

Good point Jacob.

A side question, what exactly is the difference between default and context in regards to setting variables?

Thanks.

[David Ward]

I'm have just been using default, it seems to be working. Not sure of the use of context.

[borromeotlhs]

I believe that context overrides default settings.

http://docs.saltstack.com/ref/states/all/salt.states.file.html#operations-on-regular-files-special-files-directories-and-symlinks

If using a template, any user-defined template variables in the file defined in source must be passed in using the defaults and/or context arguments. The general best practice is to place default values in defaults, with conditional overrides going into context, as seen above.