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.

Reply via email to