Possibilty to have dynamic targets

[EugenMayer]

Since, other then confd or consul-template, tiller does not watch for changes in dataSources and therefor does not need to "simple compare source template and target template", there is one huge feature that confd and consul-template are missing - and thats dynamic targets.

Lets say you have several web-apps of the same type, but they all need a config.yml in

/data/instances/<instance-name>/config/config.yml

and the instances are registered in consul ( or wherever ) lets say unter

instance/<instance-name/<*all config values"

You would need to loop over every instance, and for each, depending on the instance name, create the configuration file.

Is this already possible with tiller? It would be a really great feature and one of those things which would give tiller a USP over the others

[markround]

Not at the moment. But it would probably be possible to do, I'll have a think about this...

[EugenMayer]

That would be awesome. Think about any case, even virtual-host configuration in nginx based on single files.

I think the biggest "drawback" here is probably, how files will be removed, if you "delete" an instance out of e.g. consul

[schuylr]

👍 Would be an awesome feature and might consider writing something myself here too. I want to distribute changes through my configuration without having to restart containers and having this would be a great way to do it. A check command would be imperative though in order to ensure that the new configuration wouldn't result in application errors on reload.

[EugenMayer]

I think that is now implemented, isnt it?

It does not solve the use case above, of generating "several files", basically splitting a configuration into files, but still, dynamic targets are there now.

Splitting in several files and supporting that, thinking about this twice, would be very hard to implement in tiller itself.

For anybody interested in how to do that, basically what you do is creating a fake "onefile" template for the MD5SUM checks to work, and then write out your splitted files on the file system using ruby code in the actual erb template.

This way you get:

• multiple files per template
• maintaining md5 based restarts still

Works for me very well