[chef-dev] Re: Re: 5/14 Opscode Code Review

[Daniel DeLeo < >]

On Monday, May 14, 2012 at 7:55 PM, Brad Knowles wrote:

> On May 14, 2012, at 7:38 PM, Bryan McLellan wrote:
> 
> > CHEF-3045: We lazy load a number of objects, like cookbook files and
> > templates. Access to these objects can time out if they're store
> > somewhere like S3. Should we download these objects right away by
> > default? For long Chef runs this has the benefit of moving a number of
> > potential failures to the beginning of the run. Thoughts?
> 
> 
> 
> Is it possible to keep the default set the way it is, but to allow those 
> who need it to switch the default to optimistic loading? If not, can we 
> have a method of specifying which object(s) might need to be loaded early?
> 
> It seems to me that the current default is almost always the right choice, 
> but as you have observed there are times when it may not work out so well. 
> I'm just trying to help identify relatively easy ways where we can have our 
> cake and eat it too. ;-)
For more background here, the issue is that with Hosted Chef, we distribute 
signed, time-limited URLs with an expiration of 60m to the client when 
computing its cookbook list. Andrea Campi did some work to make S3 storage an 
option for the OSS Chef server, so I believe this issue can also occur with 
OSS Chef server if you're using that feature (I haven't looked at that code 
too much outside of initial review).

If your client run takes longer than 60m, and you have a template or cookbook 
file resource that attempts to lazy load a file from the cookbook after that 
time, you get an error. Making eager loading of cookbook files and templates 
an option sort of solves the issue, in that you can configure eager loading 
after you've been bitten by this issue and found out that you need it, but 
this is a pretty bad user experience compared to never seeing the issue in 
the first place. I've also noticed that people new to chef seem to be 
confused by the lazy loading behavior (why is the template not transferred to 
the client?).

That said, I know there are some people relying on lazy loading of these 
files to avoid transferring lots of filespecificity-specific large binaries. 
So we're looking for feedback to see if changing the default behavior would 
be a net win or loss for the overall user base.

It would also be possible to implement a URL refresh to solve the problem, 
but this would require some changes to Hosted Chef, so it would be unlikely 
we could implement it soon, given the amount of work we need to do on the 
Erlang port, why run, and reporting features.
> 
> --
> Brad Knowles 
> <
 
>  
> (mailto:
 )>
> LinkedIn Profile: <http://tinyurl.com/y8kpxu>



-- 
Dan DeLeo