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

[Florian Hehlen < >]

Wow! Thanks for all the input. There is a lot to digest(pun intended) in all 
the responses, not just this one.

Cheers,
Florian

-----Original Message-----
From: Eric G. Wolfe 
[mailto:
 
Sent: 17 July 2013 01:34
To: 

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

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


LEGAL DISCLAIMER
This communication and any attached documents are strictly confidential 
and/or legally privileged and they may not be used or disclosed by someone 
who is not a named recipient. If you have received this electronic 
communication in error please notify the sender by replying to this 
electronic communication inserting the word "misdirected" as the subject and 
delete this communication from your system.