[chef-dev] Re: Re: Re: Re: Re: local file copy resource?

[Zachary Stevens < >]

Sorry about the delay replying...

On 12 Dec 2012, at 23:42, Daniel DeLeo 
<
 >
 wrote:
> On Wednesday, December 12, 2012 at 10:03 AM, Zac Stevens wrote:
> 
>> Jesse - thankyou for working on this.  Whatever form the solution takes, 
>> I'm sure I'll use it.
>> 
>> I wanted to add my 2 cents...
>> 
>> On Wed, Dec 12, 2012 at 4:48 PM, Daniel DeLeo 
>> <
 >
>>  wrote:
>>> On Tuesday, December 11, 2012 at 5:22 PM, Jesse Campbell wrote:
>>>> Okay, so what would you like to see? FileCopy provider for local file 
>>>> operations, and CookbookFile extends FileCopy? Where to put Bryan's move?
>>>> 
>>>> Happy to go about this differently, but a local option to cookbookfile 
>>>> seems backwards
>>>> 
>>> I agree a local option to cookbook file isn't the right way to go. My 
>>> favored options are either a file_copy resource and provider, or a local 
>>> option to remote file.
>> 
>> I dislike the idea of a file_copy resource - I think it's because I parse 
>> it as an imperative (copy X to Y).  On the other hand, I see how it could 
>> be read declaratively (ensure Y has the same contents as X).  
>> 
>> Permitting a local file URI as remote_file's source (eg: source 
>> "file:///path/to/source/file") makes the name of the resource a little 
>> misleading, but otherwise fits the way I currently look at the file 
>> resources:
>> 
>> file - for asserting that files are absent, or present with contents 
>> inlined in the resource declaration.
>> cookbook_file - for asserting files exist, with contents from a file 
>> shipped with the cookbook
>> remote_file - for asserting that files exist, with contents coming from 
>> elsewhere
>> 
>> That said, I find it difficult to infer the conceptual model that results 
>> in three resources distinguished in those ways.  If there is one, I'd 
>> expect to find a matching trio of template resources - if not, it sure 
>> would be nice to unify the file resources in a future, major release.
> Can you explain what you think the benefit is of unifying all the file 
> resources? Would you keep template separate (why/why not)?

All these resources (file, cookbook_file, remote_file, template) are 
concerned with a given file on my node - I'd unify them all.  I'll address 
perceived benefits below...

> As I said in a previous email in this thread, I feel there's a benefit to 
> having the implementation-specific resources (e.g., separate template vs. 
> remote_file vs. cookbook_file, etc.), since they implicitly express where 
> to look for the source file which I believe helps for code 
> reading/debugging and also allows for more brevity. To me, this is a 
> worthwhile pragmatic compromise whereby accepting some leak of 
> implementation detail into the model makes using the model in everyday 
> situations actually simpler.

I agree with the goal of helping readability, so perhaps we value the 
tradeoffs in different ways.  I feel that the implementation-specific 
resources steepens the learning curve (by increasing the number of primitives 
new users need to understand), and prematurely shift the cookbook author's 
focus away from describing the target state of their system.

I'd imagine a unified file resource to create a file with contents from an 
HTTP server like this:

file "/tmp/foo" do
    source "http://example.com/files/foo";
end

Files with contents from cookbook files might look like this:

file "/tmp/foo" do
    source "cookbook-file:///foo"    # from current cookbook
end
file "/tmp/bar" do
    source "cookbook-file://other-cookbook/bar"
end

For comparison, the second example currently would be:
cookbook_file "/tmp/bar" do
    source   "bar"             # optional, implied by name attribute
    cookbook "other-cookbook"
end

That form permits greater brevity (the source attribute can be omitted in 
this case), but I don't think it provides any additional information about 
where to find the source file.  Admittedly, the resource name may be a 
stronger cue than a source URL.  When writing cookbooks, I often find myself 
iterating over the file management in my recipes - starting by ensuring that 
a file has the right ownership and permissions, then moving its contents into 
the cookbook, before turning it into a template.  Changing the resource type 
in each step is just a little extra friction.

Implementation-specific resources can also cause additional complexity when 
parameterising cookbooks.  If I want to create a file whose contents are 
pulled from a HTTP server (if a URL is supplied in an attribute), or a 
cookbook file (if not), my recipe needs logic to declare entirely different 
resources.

Unifying file and template resources also simplifies making some assertions 
about the contents of the resource collection (eg, identifying two resources 
managing the same file).  It's not a big deal to make these checks across the 
current 4 resource types, and it wouldn't be the end of the world if that 
grew to 8 - but it is a wart.

> That said, a few people have brought up contrary opinions, and I'd like to 
> understand this. Is it just modeling purity, or do you imagine other 
> tangible benefits?

I imagine that improving the model would lead to other tangible benefits, so 
long as the resulting resource declarations don't become more complicated in 
the common cases.  For example, requiring additional attributes in every file 
resource to specify the relevant providers would be miserable.

So, the benefits I perceive are:
 * emphasises the resource as a piece of the system being managed
 * simplifies some reporting
 * reduces the number of resources a new user has to understand to be 
productive

On the other hand, the new user would also have a more complex File resource 
to learn.  I think it would be an improvement, but that's probably subjective.


Zac