Custom renderer not rendering pillars

[Seth Madison]

I am starting to play around with custom renderers, but I can't get them working quite right. I am on 2014.1.3, and am testing out with a minion and master running on the same machine.

If I create a renderer that looks like this:

    def render(data, saltenv='base', sls='', argline='', **kwargs):

        return data

in ``_renderers/custom.py`` and then I add a line to my master config file like:

    renderer: jinja|yaml|custom

I would expect that to be able to run ``state.show_highstate`` and see my highstate completely unchanged. Instead, I get an error from the minion:

    Got a bad pillar from master, type str, expecting dict:

Meanwhile, on the master, I see:

    LoaderError: The renderer jinja|yaml|custom is unavailable, this error is often because the needed software is unavailable

The renderer seems to load fine in the minion, but the master can't find it, and so my pillars do not render. I think that the MasterMinion does not get my custom _renderer, but SMinion does?

[Seth Madison]

Update: I noticed from looking at -l trace that the master was only looking in my extension directories, and not in the _renderer directory (or the extmods directory). If I just put the renderer into the extensions directory and leave it out of the _renderer directory it will not get synced to the minion. My solution for now is to have a symlink from my _renderer directory to my extension directory.

[Jason M]

Where are you placing the custom renderer?

If your base 'file_roots' is '/srv/salt' as configured In the '/etc/salt/master' configuration file, you will need to create a directory '/srv/salt/_renderer' and place your your custom renderer named custom.py in that directory.

Then I would suggest to run 'salt-call --local saltutil.sync_renderers' which will then take a copy of the file that is in '/srv/salt/_renderers' and place it in the '/var/cache/salt/minion/extmods/renderers' (this is where it will be executed from)

Then when you run 'salt-call --local state.highstate' it should run.  It should also copy it when running highstate, but I don't run highstate that often while developing; I run state.show.

I am working with the develop branch and just got a custom renderer working last night although I have not run a highstate yet.  I have been using the following command to test my individual state: 'salt-call --local  --out=yaml state.show_sls users'; where users is the state files I am testing located in '/srv/salt/users/init.sls'.  The init.sls files contains the shebang as the first line to indicate to salt to use my custom renderer.  The shebang on the very first line I use is '#!yamlscript' where my custom renderer is named yamlscript.py.

I see you added your custom renderer definition to your master configuration file and I just want to make sure you know it will be run with every state file as default.  If that is your desired plan, that's fine, but if you only want your custom renderer to work only with specific state files, just use the shebang approach as I indicated above.

If you still having issues, let hear about it so I can try some tests on my end since I have an interest to make sure this will work on other installations other than my own since I will be releasing a new renderer to the public within a week or so.

[Seth Madison]

I put the custom renderer in _renderer -- the key is that I was running a master/minion on the same machine, and I did in fact want my master to use the renderer to render pillars. sync_renderers put it into the minion's extmods directory, but not the master's, and so I had to explicitly put the renderer into the master's directory. For this use-case, I've switched to local mode, so none of this is really a problem anymore. 

--
You received this message because you are subscribed to a topic in the Google Groups "Salt-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/salt-users/Gozm24uRb4A/unsubscribe.
To unsubscribe from this group and all its topics, send an email to salt-users+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.