On Thursday, November 8, 2012 3:49:12 AM UTC-6, j4m3s wrote:
Thanks John. Yes I realised that from going through the crontab.rb
and parsedfile.rb scripts.
You are absolutely correct that there is nothing that could easily be
lifted and used on top of puppet.
I believe that, in order to make this work, a change would be required
to one or more of the core template funtions in puppet - possibly to
add a "flag" to say to include the last-updated header (or call a
separate templateWithHeader function) , and to later ignore it when
parseing the files to check for changes.
Nope. There is no way the issue could be solved by modifying the template
functions, because they have nothing to do with checking file content for
changes. I outlined already what would be needed: a file with a
content-timestamp header would need to be treated as at least two parts (a
composite *resource* -- header and body). It might be possible to build
something like that on top of the Concat module, which is all about
building files from pieces. Even if not, it's at that level (resource
type) where the problem would need to be addressed.
The fact that the comment
marker would be different in some cases does complicate matters - but
not insurmountably. It could default to being determined based on the
file extension (the part before the .erb) and the function could take
a parameter that overwrode it if required. It's a common process when
auto-generating source file headers for copyright in maven projects
for example (where there are some java files, some sql files, some xml
The problem is not with generating or formatting the header, it's with
ignoring the header when the file content is checked to see whether it's in
sync. The template functions have nothing whatever to do with that.
I'm actually a Java guy by background so am loving the power of puppet
but struggling someone to make anything more than the most basic
puppet functions. That said, if I get the chance I would love to code
or contribute to an enhancement like this, if it would be valued by
I wouldn't personally use it. For me,
1. It only matters that the content is in sync, not when it was
2. If I wanted to know when the content was generated, then I would be
content to rely on the file's modification timestamp as recorded by the
3. The extra complexity involved in managing a content timestamp would
produce extra work for the master and extra space for bugs.
Indeed, if I were looking for something along these lines, it would more
likely be a *template* version or timestamp than a content timestamp, and a
template timestamp doesn't need any special support.
For me, the benefit of the header is being able to immediately tell
whether the file has been modified by someone or something since the
last puppet run (by comparing the header to the last modified
timestamp on the file). It's very helpful when fault-finding. It
also gives a nice straightforward view (from within the file itself)
of the last time it changed - again helping to narrow down the source
I understand. I just don't have concerns along those lines with the files
I am currently managing on any of my hosts. I also think you may be
overlooking some of the implications of the Puppet agent keeping managed
files in sync -- unlike once- or rarely-generated files, files with
Puppet-managed content can be re-generated up to once every Puppet run
(with new content timestamps, if any). Manual changes will be clobbered on
that schedule, which is once every 30 minutes by default. As a result,
admins will quickly learn not to make manual changes to managed files, and
if they do make such changes then you can always tease out the information
you want (with more difficulty) from the Puppet log.