[chef] Re: Re: Re: [Chef] Write current date to template, when it changes

[Jesse Nelson < >]

I solved this problem initially in my local bind cookbook by using
$INCLUDE in the bind zone file, and having the included  records
template notify the parent zone template. In that zone template I
simply do a time stamp for serial. I then ended up abandoning this
method and writing an lwrp for nsupdate cause I wanted to be able to
add records to a zone that's getting dhcp updates.

I am cleaning up this cookbook for release, and hope to have something
out next week If you're interested.

- Jesse
On Thu, Mar 8, 2012 at 7:32 AM, John E. Vincent (lusis)
<
 >
 wrote:
> On Thu, Mar 8, 2012 at 10:19 AM, Bryan McLellan 
> <
 >
>  wrote:
>> On Tue, Mar 6, 2012 at 9:29 AM,  
>> <
 >
>>  wrote:
>>> I want to write a cookbook for a bind. My problem is, that I don't know 
>>> how I  can generate the timestamp (serial) without changing the template 
>>> everytime.
>>
>> The template provider renders the template to disk and then compares
>> it with the existing file using a checksum. Thus you can't easily do
>> this.
>>
>> One solution could be to set the time field in the template to a
>> static placeholder like TIME_BASED_SERIAL and set the template path to
>> a temporary directory near the real file. Then create an execute or
>> ruby_block resource with its default action set to nothing. Have it
>> replace that value with a generated time and move the file into the
>> production location. Notify this resource from the template resource
>> and then notify the reload of the service with this one.
>>
> <snip>
>> Bryan
>
> I wonder if it's not time for a new convenience construct that
> understands incrementing counters like that. Zone serials are the only
> place I can think of immediately where this is helpful but I'm sure
> others have more use cases.
>
> Maybe something even more generic. Do notifications for templates
> work? The end result here (and I'm typing this for MY benefit to think
> about it) is that the template construct either needs to understand
> subtleties around content vs. header? This might just need to be an
> LWRP that tracks the serial via a data bag somewhere?