On Wed, Mar 10, 2010 at 12:47 PM, Mathew Binkley <mathewbink...@gmail.com> wrote: > On Wed, Mar 10, 2010 at 9:59 AM, Michael DeHaan > <mich...@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. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
