Allow templating local files

[dnd]

Currently file.managed does not allow templating of local files. There have been a few times I have had files inside of a git repo that I have cloned to a server and wanted to template them in the current context. Unfortunately that doesn't seem possible at the moment.

[whiteinge]

Thanks. This would be a useful addition.

[terminalmage]

This should work... IIRC, the file.managed state caches the file in the minion cache and renders the template there before comparing it to the targeted file. This might actually be a bug. I'll investigate.

[terminalmage]

Ahh, OK, so I was mistaken. It appears that local files cannot be used as a source for file.managed states, period. So it's not simply a matter of templating not working.

[whiteinge]

I would like to have a standalone "render" execution module so you can tap into the renderer system from arbitrary places. Plus it could be reused in other modules that are currently repeating the templating boilerplate code. I started on an implementation -- probably can't finish this week but I think I can make it happen before the Helium RC.

[terminalmage]

OK, just FYI the rendering code is also in the cron.file state, I abstracted it a long time ago. So, if you make any changes, refs in salt/states/cron.py will also likely need to be updated.

[cro]

@whiteinge: me too--I envision using it to ease config file management during application development.

C. R. Oldham, Engineer, SaltStack
cr@saltstack.com

On Jul 1, 2014, at 4:50 PM, Seth House notifications@github.com wrote:

I would like to have a standalone "render" execution module so you can tap into the renderer system from arbitrary places. Plus it could be reused in other modules that are currently repeating the templating boilerplate code. I started on an implementation -- probably can't finish this week but I think I can make it happen before the Helium RC.

—
Reply to this email directly or view it on GitHub.

[yanatan16]

I have been templating local files with file:// prefix with file.managed for a while, but that broke when i pulled the latest develop. It was working on the latest stable (v2014.1.5)

My test case:

# salt-call state.single file.managed name=/tmp/docker-builds/devsite-server/Dockerfile source=file:///src/devsite/config/Dockerfile.configured template=jinja
[INFO    ] Loading fresh modules for state activity
[INFO    ] Running state [/tmp/docker-builds/devsite-server/Dockerfile] at time 16:08:37.788876
[INFO    ] Executing state file.managed for /tmp/docker-builds/devsite-server/Dockerfile
[ERROR   ] Unable to manage file: No connection adapters were found for 'file:///src/devsite/config/Dockerfile.configured'
[INFO    ] Completed state [/tmp/docker-builds/devsite-server/Dockerfile] at time 16:08:37.793651
local:
----------
          ID: /tmp/docker-builds/devsite-server/Dockerfile
    Function: file.managed
      Result: False
     Comment: Unable to manage file: No connection adapters were found for 'file:///src/devsite/config/Dockerfile.configured'
     Started: 16:08:37.788876
     Duration: 4 ms
     Changes:

Summary
------------
Succeeded: 0
Failed:    1
------------
Total states run:     1

[stas]

We've recently stumbled upon a similar issue. It would be very handy to have the file:// source type support for file state.

----------
          ID: deploy_app_static
    Function: file.recurse
        Name: /var/www/app/static/
      Result: False
     Comment: Invalid source 'file:///var/www/git/static' (must be a salt:// URI)
     Changes:   
----------

[terminalmage]

This is fixed in #14228, and I've added tests to keep this from regressing again. Thanks for reporting, we should be able to get this into the next release.

[stas]

💃