Load user defined template engines

[baby-gnu]

Description of Issue/Question

Hello,

Actually, only SLS can have custom renderers which could be provided under <base>/_renderers/.

As far as I understand:

• salt.renderers.* are for SLS
• salt.utils.templates is for template files
• salt.utils.templates has an hardcoded list of template engines

Is it possible to make salt.utils.templates extendable like salt.renderers?

Regards.

Setup

(Please provide relevant configs and/or SLS files (Be sure to remove sensitive info).)

Steps to Reproduce Issue

(Include debug logs if possible and relevant.)

Versions Report

(Provided by running salt --versions-report. Please also mention any differences in master/minion versions.)

Salt Version:
           Salt: 2016.3.4
 
Dependency Versions:
           cffi: Not Installed
       cherrypy: 3.5.0
       dateutil: 2.4.2
          gitdb: Not Installed
      gitpython: Not Installed
          ioflo: Not Installed
         Jinja2: 2.8
        libgit2: Not Installed
        libnacl: Not Installed
       M2Crypto: Not Installed
           Mako: Not Installed
   msgpack-pure: Not Installed
 msgpack-python: 0.4.6
   mysql-python: Not Installed
      pycparser: Not Installed
       pycrypto: 2.6.1
         pygit2: Not Installed
         Python: 2.7.12 (default, Nov 19 2016, 06:48:10)
   python-gnupg: Not Installed
         PyYAML: 3.11
          PyZMQ: 15.2.0
           RAET: Not Installed
          smmap: Not Installed
        timelib: Not Installed
        Tornado: 4.2.1
            ZMQ: 4.1.4
 
System Versions:
           dist: Ubuntu 16.04 xenial
        machine: x86_64
        release: 4.4.0-51-generic
         system: Linux
        version: Ubuntu 16.04 xenial

[whiteinge]

I don't know the reason that salt.utils.templates are a thing. (I've asked around and I'll report back if I learn anything.) I think you're exactly right that they should be pluggable like other Salt modules or that we should just call renderer modules directly instead of going through a template wrapper.

What is your end-goal? Are you wanting to do something like use a custom renderer module with the file.managed state? If so, there's a couple potential alternatives available.

1. You could call out to the slsutil.renderer execution module which should be able to use your custom renderer module. The downside is it doesn't have a corresponding state module yet.

   https://docs.saltstack.com/en/latest/ref/modules/all/salt.modules.slsutil.html#salt.modules.slsutil.renderer

2. Depending on your use-case you could write a serializer module instead. Serializer modules are modules that accept a data structure and transform that into a specific result -- a string representation of that data structure.

   https://docs.saltstack.com/en/latest/ref/states/all/salt.states.file.html#salt.states.file.serialize

   The docs are wrong, it works with all serializer modules. (Fix in Fix incorrect file.serialize docs; all serializer modules are supported #38190.) They can be loaded via a _serializers directory as expected.

   https://docs.saltstack.com/en/latest/ref/serializers/all/

[baby-gnu]

Thanks for the reply, my end goal is to use a custom renderer module with file.managed state.

It's actually a little more complicated, the idea is to switch progressively to full SaltStack, but we actually have templates and data repository with a templating engine, we just want to call that system within file.managed.

Looking at the code, we have another issue, the “foreign” system provides its own templates, the state do not need the source parameter since it's not managed by salt and, unfortunately, the templating is applied only when a source is provided.

I actually managed to work around this by creating a state module (a prototype for now) to do directly call the “forgein” system:

The SSHd configuration file:
  eole.file:
    - name: /etc/ssh/sshd_config

So we provide python-salt.states.eole module with a file function doing what we want.

We do not have all the fancy features of file.managed but it does the work for now.

Regards.

[whiteinge]

Thanks for the detail. Interesting.

Since you have your own state module that slsutil.renderer may be a workable option since you could perform your own idempotent checks by either rendering to a temp file or tracking another way to tell if the file needs to be swapped out or not.

[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.

[baby-gnu]

Hello.

Unfortunately there is no news on this topic for a long time.

It looks to me that the situation did not evolve the salt.utils.templates still use an hard coded list of engines.

For me there is no way to easily benefit of all the work done by salt.states.file.managed with a custom template system, I need to duplicate everything :-/

Any chance for something to change here?

Regards.

[stale[bot]]

Thank you for updating this issue. It is no longer marked as stale.

[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.

[baby-gnu]

Same as above, nothing moved here, the list is hard coded.

As we moved forward to something else we are less interested in this feature, if you think it's a waste of time and nobody cares you can close it.

Regards.

[stale[bot]]

Thank you for updating this issue. It is no longer marked as stale.

[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.

[stale[bot]]

Thank you for updating this issue. It is no longer marked as stale.

[sagetherage]

@dwoz can you follow up on this Pending Discussion ticket, please?

[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.

[baby-gnu]

ping

[stale[bot]]

Thank you for updating this issue. It is no longer marked as stale.

[sagetherage]

kicking this back into triage to attempt to get movement on it

[dmurphy18]

assigning this to @dwoz as to whether this feature request will be incorporated.