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

Michael DeHaan
Wed, 10 Mar 2010 17:59:35 -0000

On Wed, Mar 10, 2010 at 12:47 PM, Mathew Binkley
<mathewbinkley@gmail.com> wrote:
> 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.


It can''t, because what you are managing is the root directory
"/",
which also includes potentially conflicting
things like the permissions on those directories.

In your case, you could just use an Exec with an rsync.

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


It could be said that time saved now does not mean time saved later.

Best practices around infrastructure are useful, and it does not take
up a tremendous amount of work to set up an RPM build
environment.

Some initial pain will be worth it down the road and keep you from
getting into a mess later.