"recursive" attribute on "directory" resource does not apply users and groups to entire path

Details

  • Type: Bug Bug
  • Status: Open Open
  • Priority: Major Major
  • Resolution: Unresolved
  • Affects Version/s: 0.9.6
  • Fix Version/s: None
  • Component/s: Chef Client
  • Labels:
    None
  • Environment:

    Running Chef 0.9.6 on CentOS 5

Description

I am trying to set up a specific hierarchy of directories which must have correct permissions and owners. I do this:

directory "/data/realtime/fetched/radar" do
action :create
owner "ldm"
group "ldm"
mode "777"
recursive true
end

After that, I expect /data, /data/realtime, /data/realtime/fetched, and /data/realtime/fetched/radar directories to all exist, have owner "ldm", group "ldm", and permissions of 777.

Instead, all the directories exist, but only /data/realtime/fetched/radar has the correct user, group, and permissions; all others are owned by root (which ran chef-client) with 755 (default) permissions.

The documentation for this attribute comes from

http://wiki.opscode.com/display/chef/Resources#Resources-Directory

which is not perfectly clear. This "bug" may be a bug in the code, which is doing the wrong thing by not respecting the "recursive" directive; or it may be a "bug" in the documentation, resulting in users like me not knowing exactly what the "recursive" attribute does. If I am expecting too much of the "recursive" attribute, then it would be good to expand the documentation to explain that "recursive" creates directories recursively, but does not apply other attributes recursively.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Daniel DeLeo added a comment -

We had a discussion about this behavior on the Chef developers list:

http://lists.opscode.com/sympa/arc/chef-dev/2010-10/msg00006.html

In short, I think we came to a consensus that applying ownership and ACL settings to the intermediate directories chef creates with no further intervention from the user is not a very good behavior because this settings will not be changed if you update them in the resource since Chef would no longer know at that point that it was managing the intermediate directories.

Instead, there should be an explicit property of the resource setting the top-level directory to be managed is, something like

directory "/data/realtime/fetched/radar" do
  # other stuff...
  recursive(true)
  managed_from("/data/realtime")
end

That way Chef will know to manage the ACL settings on /data/realtime, /data/realtime/fetched, and /data/realtime/fetched/radar, and can update the directories as the settings in the resource change.

It's not clear yet what the best name for that property would be, we've looked at "recurse_upto", "recurse_downfrom", and now I've added "managed_from"...

Show
Daniel DeLeo added a comment - We had a discussion about this behavior on the Chef developers list: http://lists.opscode.com/sympa/arc/chef-dev/2010-10/msg00006.html In short, I think we came to a consensus that applying ownership and ACL settings to the intermediate directories chef creates with no further intervention from the user is not a very good behavior because this settings will not be changed if you update them in the resource since Chef would no longer know at that point that it was managing the intermediate directories. Instead, there should be an explicit property of the resource setting the top-level directory to be managed is, something like directory "/data/realtime/fetched/radar" do # other stuff... recursive( true ) managed_from( "/data/realtime" ) end That way Chef will know to manage the ACL settings on /data/realtime, /data/realtime/fetched, and /data/realtime/fetched/radar, and can update the directories as the settings in the resource change. It's not clear yet what the best name for that property would be, we've looked at "recurse_upto", "recurse_downfrom", and now I've added "managed_from"...
Hide
Permalink
Michael Stillwell added a comment -

Is it possible to update the documentation now, though? The current behaviour does eventually make sense (in the absence of a "managed_from" property, but not the first time you think about it!

Show
Michael Stillwell added a comment - Is it possible to update the documentation now, though? The current behaviour does eventually make sense (in the absence of a "managed_from" property, but not the first time you think about it!
Hide
Permalink
Lamont Granquist added a comment - - edited

IMO, this should get wrapped in an LWRP that dynamically creates directory resources and the recursive option to directory should be deprecated.

recursive_directory "/data/realtime/fetched/radar" do
  managed_from "/data/realtime"
end

or maybe equivalently:

recursive_directory "/data/realtime/fetched/radar" do
  depth 3
end
Show
Lamont Granquist added a comment - - edited IMO, this should get wrapped in an LWRP that dynamically creates directory resources and the recursive option to directory should be deprecated. recursive_directory "/data/realtime/fetched/radar" do managed_from "/data/realtime" end or maybe equivalently: recursive_directory "/data/realtime/fetched/radar" do depth 3 end

People

  • Assignee:
    Unassigned
    Reporter:
    Nicholas Keene
Vote (0)
Watch (5)

Dates

  • Created:
    Updated: