Managing folder trees - best practice?
JonY
jcbollinger
It sounds like you could probably approach this with the File type's 'sourceselect' parameter. If you use "sourceselect => 'all'" and a 'source' parameter specifying a multi-element array, then you indeed can get a sort of merging behavior that I think could be made to serve your needs.
John
Wil Cooley
On Nov 1, 2014 5:46 AM, "JonY" <ethr...@gmail.com> wrote:
>
> Along comes an eager dev who says "I want to split this tree into two types - the difference between these being ~5% of the files."
>
> My choices for managing this tree seem to boil down to:
>
> 1. Berate the dev. Not v satisfying - like yelling at a puppy.
> 2. Maintain two (nearly identical - but not quite) file trees. It's all in git so maybe this isn't so bad. Looks messy though. Means having to sync nested trees and keep them straight.
> 3. Change the tree structure of what's being copied in and don't recurse. Name every sub folder in the 'file' resource according to which node get what. Neater than #2 but lots of extra work.
> 4. Create a 'merge' solution so I keep the current folder structure and only merge in the changes for the impacted nodes.
>
> #1 - lots of unhappiness
> #2 - seems prone to error
> #3 - extra work. probably what will happen though.
> #4 - seems like the most obvious but (AFAIK) it's not supported by puppet.
>
> Is there something better? Another choice I've neglected?
Are these trees "releases" (however you define it) from your devs? Are the files (especially the ones that don't differ) large or very numerous?
If they're releases, then you should use what they give you and not try to maintain changes on top of their releases that are outside of their process. If there are changes they could make to help your deployment, such as making more granular releases, work with them to integrate that into their processes.
But if that isn't feasible, I wouldn't necessarily bother to try any more deduplication unless the files were very large or numerous and disk space at a premium -- that's likely to lead to more trouble & work down the line and your time may easily cost more than you save.
In any case, you might consider other approaches to file resources -- it's really not intended for large numbers of files and probably not the best way for your Puppet master to spend it's CPU time if you have now than a few dozen nodes. Depending on how the "release" is delivered to you, you might consider packaging and installing it with a package resource, using the 'staging' module, using a 'vcsrepo', rsync in a cron job or exec resource, etc.
Wil
Felix Frank
> 2. Maintain two (nearly identical - but not quite) file trees. It's
> all in git so maybe this isn't so bad. Looks messy though. Means
> having to sync nested trees and keep them straight.
> 3. Change the tree structure of what's being copied in and don't
> recurse. Name every sub folder in the 'file' resource according to
> which node get what. Neater than #2 but lots of extra work.
> 4. Create a 'merge' solution so I keep the current folder structure
> and only merge in the changes for the impacted nodes.
are you aware that this works:
class base {
file { '/etc/foobar': recurse => true, source => ... }
}
class different {
file { '/etc/foobar/subdir/file': ensure => file, ... ;
'/etc/foobar/subtree': ensure => directory, ...
}
}
include base
include different
The files/directories underneath /tmp/foobar that are managed explicitly
(via class different) are exempt from recursion. This might allow you to
declare the exceptional case in a more sparse fashion.
HTH,
Felix