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 > files etc). > 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 > the community. > I wouldn't personally use it. For me, 1. It only matters that the content is in sync, not when it was generated. 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 file system. 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 > of problems. > 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. John -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/dR-yGuVifmkJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
