[chef] Re: Re: Re: best practices

[Arnold Krille < >]

Hi,

On Tue, 16 Jul 2013 13:33:19 -0400 "Eric G. Wolfe"
<
 >
 wrote:
> For uninstallation, I like the idea of an "undo" recipe.  For
> example, RHEL flavors tend to install NFS as part of the base
> installation.  When I set out to do the nfs cookbook, I was sure to
> create an "nfs::undo" run-once recipe
> <http://community.opscode.com/cookbooks/nfs/source> which will clean
> up that annoyance.  The annoyances cookbook is another good example
> of reversing an undesired state on a managed node.
> 
> I think the idea of an undo recipe should be to step backwards
> logically through the installed/running pattern.  Run-once capability
> is a nice thing to have for a "kickstart" type of role.  For example,
> I may want to undo nfs on every fresh installation.  However, I don't
> want the "nfs::undo" recipe to permanently exist in the run_list and
> reverse the state of an actual NFS server either.

Hm, but all recipe should be "run once" recipes. Regardless what the
state before is, the end state should always be the desired one. So as
it shouldn't hurt to "install" nfs-server on each chef-client run, it
also shouldn't hurt to uninstall nfs on each chef-client run.
Only when you apply your "nfs::uninstall" and "nfs::server" recipes on
the same node at the same time...

So as I don't care when chef-client makes sure vim-nox is installed on
each system (to make sure my co-workers don't leave me an unusable
machine), I also don't care when chef-client makes sure that emacs
isn't installed even when some co-worker decided to do a quick "apt-get
install" just because.

So I actually fail to see a special need for making sure recipes only
run once. No matter what they do, they should always lead to the
desired outcome, regardless whether that means doing something or not.

Have fun,

Arnold

Attachment: signature.asc
Description: PGP signature