Re: [Puppet Users] How to efficiently manage multiple packages installing in the same directory

Mathew Binkley
Wed, 10 Mar 2010 17:47:19 -0000

On Wed, Mar 10, 2010 at 9:59 AM, Michael DeHaan
<michael@reductivelabs.com> wrote:

> Yeah, I would recommend not doing this, and would want to know more
> about the use case around why you wanted to do it that way.

Hi Michael (and Patrick and Claus).  We are in heavy development of a
storage app, as well as collaborating with several universities in
testing their own applications on a storage network we manage.  We
would like to make sure machine X is always running the latest
versions of applications Foo and Bar.

We want to use a flat folder of files because it''s quick and simple
and doesn''t require writing debian build files, RPM specs, or
otherwise having to package the files up in any way given that we are
constantly (every few days) updating binaries and configs.  I don''t
mean simply upgrading an existing file, I''m talking about adding new
files and removing old files.   Essentially we''d like to use Puppet as
an rsync-like tool, albeit with a lot more intelligence and
flexibility.

> The error you get is because Puppet will not allow the same resource
> to be represented twice, but the larger problem is you''re also
kind of
> subverting the point of the package manager
> if you are overlaying files all over the file system.

I know that''s generally true, but in this instance, each
package''s
file are orthogonal.   Only package foo will have /etc/foo.conf.  I
was expecting that Puppet could manage multiple File "/" statements as
long as the files for each package on the Puppet server were unique.

> If you''re not deploying a full app, just perhaps a set of data
files
> or content, be more specific about where it should go:

In a static environment your point make sense.  However we and our
other collaborators are adding/removing files at a furious rate, and
I''d like to avoid spending 15 minutes each time tweaking Puppet config
files.  I know that this is far from the typical use case, but I do
believe it is a *valid* use case.