Watch templates for changes on disk

[inean]

Currently, consul-template doesn't detect changes on template contents. It would be good if consul-template could update internally template dependencies (watches, etc) and template contents when it's updated on disk.

[sethvargo]

This cannot happen until Go has native file watching functionality. There is another closed issue with more information, but I cannot find it right now. #90 would also indirectly fix this because you could SIGUP on a template change.

[mfischer-zd]

This cannot happen until Go has native file watching functionality.

Why can't it watch for mtime or inode number changes?

[amiorin]

I'm using monit for that : http://mmonit.com/monit/documentation/monit.html#FILE-CHECKSUM-TESTING , but I think consul-template should implement some type of workaround because of this limitation of Go. I'm learning Go right now.

check file consul-discovery with path /etc/reverse/discovery.conf
  if changed checksum then exec "/usr/bin/pkill -HUP consul-template"

[armon]

I think we should tag this as a future enhancement. @sethvargo thoughts? I think for now, using the reloading with SIGHUP is a workable alternative.

[sethvargo]

@armon I think we need to solve #64 first too, since having a proper dependency graph would be required so we know which deps map to a file on disk (and back again) in order to implement this properly.

I would prefer to leave this closed because 1. there exists a current solution for reloading configuration (SIGHUP) and 2. I would like to see a bit more demand for this issue before we invest. So far we have only had two requests for this functionality, whereas something like #64 is approaching close to 20. I am also not convinced this is something Consul Template should be responsible for personally. There are a number of considerations we will need to take into account (what if the file is deleted, what if permissions change or it is no longer readable, etc) and I would like to hear from more people from a few different organizations about their use case(s) before investing heavily into this functionality. Make sense? Thoughts?

[mfischer-zd]

These are all great considerations. But how to accomplish this, what prioritization work should have relative to other issues, and so forth, are all variables independent from whether the issue exists and can/should be fixed. In my view as a customer, an issue should be closed when, and only when, it is permanently disposed of in one direction or another.

[sethvargo]

@mfischer-zd ^

[mfischer-zd]

Great, thanks!

[armon]

@sethvargo Agreed. I think SIGHUP should be documented as a way to solve this for now, and leave it on back burner, as the multi-pass dependency resolution is much more important.

[sean-]

File system watches... one of the less enjoyable problems to solve correctly. HUP sounds fine to me. For color (and humor):

https://www.youtube.com/watch?v=vm1GJMp0QN4&start=2475

[rotatingJazz]

How about an option that would "reload" the file every X seconds?

[wwalker]

+1

I think the expectation is that if the template is modified, one would expect the target file updated.

[armon]

After thinking this through further, we've decided against implementing this. The primary reason is that it makes it hard to stage changes to the template and control the roll out. Using an explicit SIGHUP allows for fine grained control of the reloading, where automatic reloading does not. In addition, this would introduce more complexity to the project. Instead, using a SIGHUP is a standard approach almost all software uses to handle configuration file updates.