[chef] Re: Re: Re: Re: chef + managed-directory pain

[" " < >]

Hi Dan,

> I can't recall anyone asking for this before.


My understanding of an configuration management system is to bring back the node to full compliance at ANY moment, maybe this is only my understanding. There are many applications with "conf.d"-directory's or "include"-directory's. All of these applications i can't bring back to full compliance at the moment.

> To get the behavior you describe, you'll need to write an LWRP, or modify the one you found. You can see
> how remote_directory gets its list of files here:

>

> https://github.com/opscode/chef/blob/master/chef/lib/chef/provider/remote_directory.rb#L92-96

>

> And to that you'd add the ones you're managing with file/template resources, using the same approach as the > LWRP you referenced. Then you could nuke any "rogue" files.

Please look at the caveats of the LWRP i've referenced:

https://github.com/zts/chef-cookbook-managed_directory#caveats

The LWRP uses "run_context.resource_collection.all_resources", but thats not useful.


For example, i have to add an apt-repo file:

apt_repository "ubuntu-main" ...


Then "run_context.resource_collection.all_resources" shows:

apt_repository[ubuntu-main]


But it doesn't show that this resource will add the file "/etc/apt/sources-list.d/ubuntu-main.list" .


What you need to realize managed directory's is an index of the files with full paths that are changed/created through all resources in the chef-run.

This index/list has to generated right at the start of an chef-run. With this list a LWRP can detect which files are managed by chef (through a file, template, etc. - resource) and which aren't.

I haven't found this in chef, or did i miss something ?


--
Bjoern

2012/8/23 Daniel DeLeo < " target="_blank"> >

Sent this from the wrong email address, my reply is below.

-- 

Daniel DeLeo

On Thursday, August 23, 2012 at 8:49 AM, Daniel DeLeo wrote:

On Wednesday, August 22, 2012 at 6:44 PM, " target="_blank"> wrote:

Hi,

maybe my explanation wasn't clear enough.


The goal is to have only files managed by chef in a directory ( imagine /etc/apache2/conf.d/ or /etc/apt/sources.list.d/).

On most systems you don't know what's in these directories (for example bringing existing/legacy systems under chef control)


Example:

#delete unmanged files in directory "/etc/apache2/conf.d" ("empty" is an empty-directory (only with a .placeholder file because chef fails if the
source-directory is empty). With this approach you can clean out a directory:

remote_directory "/etc/apache2/conf.d" do
  source "empty"
  mode "0755"
  files_backup 0
  recursive true
  purge true
end


#generate (config)-file
file "/etc/apache2/conf.d/charset.conf" do
  content "some content\n"
end


The problem with this approach is that now on every chef run the file gets recreated and for a short period of time the file is unavailable (and for example if you use notifications on the file resource these are triggered now on every chef run even when the file content hasn't changed)

I can't recall anyone asking for this before. To get the behavior you describe, you'll need to write an LWRP, or modify the one you found. You can see how remote_directory gets its list of files here:

https://github.com/opscode/chef/blob/master/chef/lib/chef/provider/remote_directory.rb#L92-96

And to that you'd add the ones you're managing with file/template resources, using the same approach as the LWRP you referenced. Then you could nuke any "rogue" files.

-- 

Daniel DeLeo