[chef] Re: Re: Re: Re: best practices

["Eric G. Wolfe" < >]

The crux of the matter is the conflicting state of two, or more, 
opposing recipes.  If the removal of the undo/uninstall recipe is 
guarded so that it defers to the conflicting recipe only when there is a 
conflict in the run_list, there should be no other issue with 
idempotence within that recipe.

I would tend to disagree that every recipe should be "run once" 
complete.  While every recipe running only once and producing the 
correct state would be certainly be optimal.  The important point is to 
*eventually* reach the correct state.  If that takes two subsequent 
runs, rather than only once (in certain cases) it should not be a deal 
breaker so to speak.

Anyhow, thank you for the suggestion.  I have taken action to guard 
self-removal of the recipe, only when there is certain state conflict in 
the run_list.

Eric G. Wolfe
Senior Linux Administrator,
IT Infrastructure Systems
--------------------------------------
Marshall University Computing Services
Drinko Library 428-K
One John Marshall Dr.
Huntington, WV 25755
Phone: 304.942.3970
Email: 

 

You will be recognized and honored as a community leader.

On 07/16/2013 05:05 PM, Arnold Krille wrote:
> 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