no way to generate filenames from templates

[Steve Baker]

For example, the following template would generate a different file for each entry in confs:

{{#confs}}/etc/foo/{{bar}}.conf{{/confs}}
^--- first line has output paths--^
Content goes here {{reference variables}}
Add lines
etc.

This would be useful for heat software config, where a server's metadata contains a list of actionable data, one for each software deployment resource associated with that server.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/61364

[Robert Collins (lifeless)]

Hi, this is an interesting proposal. But I think the approach is overly limiting if we're going to allow dynamic file name specification.

The first line of a template isn't special today, and making it special will be super surprising.

This needs some design work: specifically we need to make sure this doesn't conflict with the simple case of file in -> file out, while still solving your problem (that I don't quite follow).

The pattern you've expressed is a little concerning for me because bad data could write a custom root ssh key to /root/.ssh/passwords, for instance.

So - lets gather your requirements, come up with a secure, robust design, and then this can move forward.

[Clint Byrum (clint-fewbar)]

Robert, I actually did discuss this at length with Steve Baker, but I never fully expressed my intention here and had actually intended to do a bit more documentation of it before implementation was started.

The things that are missing:

* These are path-templates, and would be treated differently than regular templates. The first line would not be special in normal templates. Where to store them was something I hadn't decided on yet.
* The first line is a single pattern, not TARGETS=
* The referenced variables themselves must not have slashes. We won't allow substitution of hierarchy. The template author controls where you can write these still, but gives up the contents of the directory to the metadata.
* The whole template would need to be rendered with the block context from the path _and_ the rest of the metadata, which may be tricky unless pystache lets us pass in an active context.
* The use case for this is to be able to write things into a .d type directory structure. So given metadata like this:

apache:
  vhosts:
    - hostname: foo.com
      port: 80
      document_root: /srv/foo.com
    - hostname: bar.org
      port: 8000
      document_root: /srv/bar.org

Your path-controlled template would be

{{#apache.vhosts}}/etc/apache2/conf.d/{{hostname}}.conf{{/apache.vhosts}}
<VirtualHost *:{{port}}>
  DocumentRoot {{document_root}}
  ServerName {{hostname}}
</VirtualHost>

Steve Baker had another use case for it that made sense.

[Steve Baker (steve-stevebaker)]

I don't think my use case is valid any more, but here it is for posterity.

Polled metadata contains a list of configuration scripts. Using this mechanism each script could be written out as os-refresh-config scripts which get run during post-configure.

This has some issues however:
* os-apply-config executes executable scripts straight after it generates them
* each script needs to be invoked with its own set of inputs, which implies writing out a wrapper script with loads the inputs then executes the actual script

My current approach is to write out all of the metadata required to a json conf file, and just have a static python os-refresh-config script which loads the config, writes out scripts, and invokes them with the appropriate environment, and signals the result.

[Alexis Lee (alexisl)]

Ideally we'd be able to add extra files into the conf.d directory of an already running instance by simply stack-updating a section like this into the metadata:

    oac:
      - body: "lorem ipsum dolores {{neutron.host}}"
        path: "/etc/maud/conf.d/xyzzy"
        control:

This would be a simple extension to the os-apply-config os-refresh-config script.