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

[John Dewey < >]

Or just use the apt resource as it was intended.  If worried about what is in the directory, build a parallel system all through chef, so that there are no surprises.  I always found it cumbersome to add config management onto a system with an unknown state.  It only half solves the real problem.

John

On Thursday, August 23, 2012 at 2:16 PM, Joshua Miller wrote:

Why not just do a rm -rf every run and put a time now in the template as a comment.  This will ensure its gets rewritten every chef run.

Ugly yes but works.

Joshua

On Aug 23, 2012, at 1:38 PM, Daniel DeLeo < "> > wrote:

On Thursday, August 23, 2012 at 1:20 PM, "> wrote:

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.

What I meant with this comment is that there hasn't been enough interest in this feature for it to have been implemented for you, so you'll have to implement it yourself.

 

> 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.

In the example you posted before, you were managing a directory with remote_directory,and also managing some individual files within that directory via file and template resources. The LWRP uses only the name/path attribute of resources to figure out which files in the directory are managed by Chef. I'm suggesting that you can improve upon the LWRP by using the logic in the code I linked to find out which files are managed via remote_directory. This would work for your earlier example.

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 is pretty difficult if you include the side effects from running scripts (which may be triggered by a package install). If you do end up hacking something together, it's probably easiest to add a whitelist to account for these. Alternatively, if you stick to built-in resources only, and avoid running scripts that create files in these directories, you can get the full list of chef-managed files in these directories using logic as I described above. Chef doesn't require that scripts, LWRPs or user-defined code specify a list of files it may create or manage, so you'll need to account for this yourself if you intend to use them.

 

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

-- 

Daniel DeLeo