Peter Meier wrote:
With Puppet, if you're just learning it, what were some of your
stumbling blocks? If you are an existing user, think back to that
time, or times when you were talking with new users?
* ssl
* ssl
* dns
* ssl certificates
Definitely understand this whole confusion point. "Bad DNS"
experiences equated for a lot of the confusion with previous projects
I've worked on, and also in trying Puppet. I think there are probably
ways to make this more clearer to the user and more troubleshootable,
though if anyone has suggestions on that, please pass them along.
* language details
* the whole puppet-doesn't-execute-things-philosophy
* getting an idea where to start
Absolutely. This is one of the big things I want to address, making
sure we make that argument very obviously and that there's a clear
learning tree to total mastery that doesn't drown you in information
initially or give you too many rabbit holes to chase down.
Part of that start is a simple writeup outlining our approach and why we
think it is the way to go. I think there's a lot of good work in
cleaning up the docs too, and you'll see alot more of that going
forward.
Part of the where to start can also be influenced by having a more
common library of examples, and yes, more tips about migrating to Puppet
on the site. Thanks!
* did I mention ssl?
I think you did!
One of the ideas I had from cobbler was "cobbler check" which was a
tool you could run to identify some of these problems. I'm not sure
if it makes sense for Puppet, but it may do some things like say "you
appear to have DNS problems resolving this, you should try..." and so
forth.
something like that would be a great idea. especially for things like
dns and ssl certs. It could provide errors if something is obvious
wrong and warnings if something is not aligned to the conventions but
could work if you set certain config options, like the master cert
doesn't contain puppet.$domain and so on.
What else might there be?
James already did a great job in providing first steps examples, like
the recent "write your own fact". However something that people like
is to have something to start with, like a first distribute your
ssh-auth key.
And then what maybe might also be nice is to provide
standalone-manifests (which require no master) which would configure
the master in a certain manner. Like the manifests to configure
puppetmaster as a rack application.
One of the things I definitely want to do is make the scaled scenarios
(ex: rack, passenger, etc) work better out of the box. I really like
this idea. Presumably we'd want to start with just the most popular
cases and tend to suggest which ones to try -- I don't think all users
of a puppetmaster want to be an expert in Ruby webserver internals and
how to choose the right one.
So something like master_webrick.pp, master_mongrel_nginx.pp,
master_mongrel_passenger.pp and so on. These would configure the
master in a standard way that works. If still people like to tweak
(destroy?) the config, they can do it, but most people could have a
safe environment with that to start. It would also be nice to have
something like: puppet_master_standalone.pp, which would configure the
master for a desktop try and test setup, where a /etc/hosts entry for
"puppet" would be created and so on. Simply that people don't have to
crawl through documentation if they missed something during setup. Oh
and for sure the obvious ::destroy classes to remove things again.
Actually the setup of puppet is more or less already quite
straightforward, however there are some corner points which shouldn't
be missed. People however still often miss them and as they are
required to get puppet successfully running, they fail and might get
frustrated.
In combination with puppetcheck this might help to nail down the
remaining bootstraping problems.
Right, exactly the point of all of this -- thanks very much for the
feedback. If anyone else has any such pointers, please share.
There's obviously a fair amount in the archives and so forth about this
as well, but I'm very open to ideas on how to make it all even smoother
(like the web server setup examples).
cheers pete
Yep. Thanks very much!
--Michael
--
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.
