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


Chronological Thread 
  • From: Jesse Nelson < >
  • To:
  • Cc: " " < >
  • Subject: [chef] Re: Re: RE: Caching Data for the Duration of a Single Chef Run
  • Date: Thu, 6 Jun 2013 19:13:37 -0700

 Wrote this exact thing bout 2 years ago for some internal cookbooks to cache search results they were using all over the place (looking up the local repo server and other things).  Worked out very nice. 


On Tue, Jun 4, 2013 at 6:20 AM, John E. Vincent (lusis) < " target="_blank"> > wrote:
At one point, I had floated the idea of an alternate search functionality that would be cached for the life of the run. Something like nodes = cached_search(:node, "blah:blah"). Wonder if that's worth discussing again.


On Tue, Jun 4, 2013 at 7:00 AM, Pitucha, Stanislaw Izaak < " target="_blank"> > wrote:
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: " target="_blank"> [mailto: " target="_blank"> ]
Sent: Monday, June 03, 2013 10:53 PM
To: " target="_blank">
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.





Archive powered by MHonArc 2.6.16.

§