Ashley Penney <apen...@gmail.com> writes: > On Tue, Nov 23, 2010 at 6:41 PM, Daniel Pittman <dan...@rimspace.net> wrote: >> Ashley Penney <apen...@gmail.com> writes: >> >> > As an example of the kind of thing we're talking about we use a product > >> called Sonatype Nexus that relies on a bunch of on disk data in > >> /srv/sonatype-nexus/. When installing the system for the first time (for > >> example, when the file{} containing the .war triggers) we would like it to > >> automatically put down a copy of /srv/sonatype-nexus/. We obviously don't > >> want this drifting out of sync with the production data which is where the > >> issue is. How do other people handle this? >> >> Package those data files yourself, if necessary including logic in the >> package to ensure that you don't overwrite valuable local changes. Then use >> puppet to ensure that package is either 'installed' or 'latest'. > > I suppose this is possible, but awkward. An example of another application > is this horrible Java CMS that we use that writes numerous XML files of > random names all over the place during operation.
Well, I agree that by the time you got as far as Java you had already lost. ;) More seriously, I can understand the problem, and it is a royal PITA. > There's cache directories, it constantly rewrites various bits of > configuration xml files, it spews logs all over. Packaging something like > that up in a way that is functional is almost impossible. When we want to > reinstall/clone that server we just copy the entire directory and then run > Puppet to change a few key XML files. Something like that is difficult to > package, and the files that you would package change frequently due to > patches and internal development on top of the CMS. I would approach that, personally, by holding my nose and using something like Capastrano or another "deploy from a version control system" tool to do literally that: copy from a golden source into the target system, by hand. Then use puppet to manage the handful of configuration files that need customization, and have the "deployment" tool trigger a puppet run with '--test' on the target machine after installation. Which is a bit nasty, and it would be nice if puppet could do it, but it sucks less than the alternatives, I think. (In other words, I think you identified the body of alternative processes well in your earlier post, although other wrappers around them might be nicer.) Daniel -- ✣ Daniel Pittman ✉ dan...@rimspace.net ☎ +61 401 155 707 ♽ made with 100 percent post-consumer electrons -- 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.