[chef] RE: Revisting an old idea


Chronological Thread 
  • From: Christopher Brown < >
  • To: " " < >, " " < >
  • Subject: [chef] RE: Revisting an old idea
  • Date: Sun, 30 Sep 2012 21:05:59 +0000
  • Accept-language: en-US

There's been some thought put into a related feature.
Rather than having me speculate here, let's take this as something that we 
should all discuss at the upcoming summit.
I totally get the value in caching these results.

-C
________________________________________
From: 

 

 on behalf of John E. Vincent (lusis) 

Sent: Sunday, September 30, 2012 12:23 PM
To: 

Subject: [chef] Revisting an old idea

At some point several months back, I had a discussion with some folks.
Maybe it was at ChefConf. Regardless, we discussed the idea of a
"cached search". Opscoded added (or maybe it hasn't made it in yet),
the idea of partial search. My suggestion/idea was that the idea of a
cached search be added that was computed once at the beginning of the
run and saved globally for the whole run. The thought was that we
frequently perform the exact same search across different recipes. For
instance in ours we have this at the top of almost every recipe:

distributor = search(:node, "role:distributor AND
chef_environment:#{node.chef_environment}").first

That's how we locate our current internal blob distribution point
(nginx serving a bunch of files for Chef in this case).

It would be pretty awesome if we only had to compute that once. I've
not tinkered with any specific implementation yet. Does the idea
interest anyone else? I was thinking either an additional parameter to
the existing search (':cached => true') or possibly a new LWRP (in the
same way I did encrypted databags before official support was there).

I've never looked at the guts of search but I'm pretty sure there are
some possible edge cases where search results would change mid-run
between recipes that could cause some nasty issue to crop up.

Thoughts?

John E. Vincent
@lusis





Archive powered by MHonArc 2.6.16.

§