Zach,

(Sorry in advance if this is a re-post and for not replying to the
original message. I replied, deleted and it never went through. On top
of that, the link to this message on Google Groups goes to another!)

Anyway... my original reply:


Chris Moates did an interesting presentation on Puppet during CPOSC a
few months back. I was actually looking at his slides for a refresher
the other day. You might find something useful in there as far as
reasons to use Puppet. He lists quite a few and why its beneficial.

You can grab a PDF of his presentation here:

http://wiki.cposc.org/_media/2008:cposc2008-moates-scalableadmin.pdf

Hope this helps!


--
Ryan Duff
web: http://www.ryanduff.net
aim: ryancduff
twitter: ryancduff



Paul Lathrop wrote:
> Zach,
> 
> Some thoughts inline:
> 
> On Mon, Feb 2, 2009 at 12:53 PM, Zach Buckholz
> <zach.buckh...@apollogrp.edu> wrote:
>> This may sound like a confusing / trick question, so please bare with me.
>>
>> What problem(s) will puppet solve? Why would I use it?
> 
> What problems do you want to solve?
> 
> Seriously, if you don't have a solid answer to this question in your
> head, I bet you will have trouble making Puppet work for you. What
> frustrates you about doing things the old "ssh + loop over hosts"
> ad-hoc shell scripting way? What fires do you spend most of your time
> putting out? What things do you find yourself doing over and over and
> over again? Answer these questions and you'll be a good way towards
> pitching your proposal.
> 
>> This is what I have come up with so far; (I wish the reductive labs site had
>> a wiki page for this)
> 
> Add one! That's what wikis are all about!
> 
>>     What is the problem?
>>         Unknown configurations
>>         Environment is not dynamic
>>         Messy
>>         No central model
>>         Hard to change
>>         No consistency
>>         Administration overhead
>>         Reactive instead of proactive
>>         Unorganized
>>         Need scripts to work with linux and solaris
>>         Hard to scale
>>
>> Can anyone add (non-technical explanations) to the above list?
> 
> I think you've covered enough ground here to make a solid argument, as
> long as you remember to tie it all back to costs. Like this:
> 
> Unknown configurations: Whenever a machine has a problem, I spend XX%
> of my time re-learning how that machine is set up before I can even
> consider what is causing the problem. If the configuration were
> consistent and self-documenting, it would free up XX hours of my time
> ($XX amount of money) to apply towards more important/revenue-driving
> tasks.
> 
> That sort of thing gets managerial types fired up. Give them a dream
> of an Operations team that is involved in producing revenue rather
> than being a cost sink.
> 
> My .02
> 
> --Paul
> 
> > 
> 


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-users@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