[chef] RE: Caching Data for the Duration of a Single Chef Run

["Pitucha, Stanislaw Izaak" < >]

I'm just using node.run_state for this - data goes into the cookbook-specific 
keys of that hash. If the data is small enough to be held in memory, I think 
that's a perfect solution.

Regards,
Stanisław Pitucha
Cloud Services 
Hewlett Packard

-----Original Message-----
From: 

 
 
[mailto:
 
 
Sent: Monday, June 03, 2013 10:53 PM
To: 

 
Subject: [chef] Caching Data for the Duration of a Single Chef Run

I've got a question about caching data for the duration of the Chef run.
Let’s assume I have an LWRP that fetches data from a remote API and that API 
is relatively slow. In my particular case that data doesn't change very 
often, and in the very off chance it changed mid-run, having stale data would 
be OK.

So my goal is to have the LWRP fetch the information one time, and cache it 
for the duration of the run. That way multiple calls to the LWRP won't result 
in many hits back to the API. 

My initial thought was to simply use Chef::Config[:file_cache_path], in 
combination with run_status.start_time so that if the cached file was older 
than the start time refresh the data. That got me to thinking why not just 
write the data directly to a sub key of run_status, and avoid all the logic 
to compare time stamps and such. Which was then followed by the question: "I 
wonder how everyone else is doing this?

So the question is essentially, what do folks recommend as the best approach 
to caching data for the duration of the run. Ideally I want to be sure I do 
something that is both 10x and 11x compatible.

Attachment: smime.p7s
Description: S/MIME cryptographic signature