[[chef-dev]] Re: [[chef-dev]] Re: [[chef-dev]] Re: [[chef-dev]] Re: [[chef-dev]]CHEF-1621 -"recursive" attributeon "directory" resource does not apply users and groups to entire path


Chronological Thread 
  • From: Daniel DeLeo < >
  • To: Chad Woolley < >
  • Cc: Seth Falcon < >, Thomas Bishop < >,
  • Subject: [[chef-dev]] Re: [[chef-dev]] Re: [[chef-dev]] Re: [[chef-dev]] Re: [[chef-dev]]CHEF-1621 -"recursive" attributeon "directory" resource does not apply users and groups to entire path
  • Date: Mon, 4 Oct 2010 09:28:36 -0700

Ohai Chefs!

On Sun, Oct 3, 2010 at 9:25 PM, Chad Woolley 
< >
 wrote:
> On Sun, Oct 3, 2010 at 9:06 PM, Seth Falcon 
> < >
>  wrote:
>> While I find the specified-user-owns-created-parents behavior least
>> surprising, I have concerns that it is ultimately not useful.  If you
>> actually need the results of that behavior, you should do it
>> explicitly else your recipe will be brittle.
>
> It does meet the principle of least surprise, and there are
> justifications for it.
>
> However, I'd like to hear the justifications for why it is "not
> useful" or "brittle".

What worries me about setting the owner/permissions on the
intermediate directories is that the final state of the system is
dependent on the starting state, so if /data (for example) doesn't
exist, you would end up with that directory owned by the user
specified in the resource, but if it does exist and is owned (say) by
root, it would stay that way. In practice, that's probably not a big
deal, since you're probably going to start from a similar OS image,
but if you were to change the user or ACL settings, Chef would only
modify the directory specified in the resource, leaving the
intermediate directories effectively unmanaged, i.e., you'd have

old setting: /data
old setting: /data/realtime
old setting: /data/realtime/fetched
this one was updated: /data/realtime/fetched/radar

>
> But I digress.  In any case, there should be a way to do this, even if
> it is a non-default option.  Having to explicitly create each
> non-root-owned directory in a tree is silly.

I think we're really discussing two things here: 1) a short-hand
syntax to have Chef manage a directory tree with a single directory
resource and 2) one possible implementation of it.

I definitely see the value in (1), but I think we can do better on
(2). For example, what if you specify the top level directory to be
managed, like:

  directory("/data/realtime/fetched/radar") do
    recursive true
    recurse_upto "/data/realtime"
    owner "not-root"
    # other settings
  end

That way Chef knows which directories in the tree to manage, and when
you change the owner or modes, Chef can update all of them.

Thoughts?

>
> -- Chad
>

Dan DeLeo



Archive powered by MHonArc 2.6.16.

§