[chef] Re: How to tell if Chef is running?

["John E. Vincent (lusis)" < >]

On Mon, Jan 24, 2011 at 12:54 AM, Noah Gibbs 
<
 >
 wrote:
> Is there a standard way to tell if your (ruby) code is being invoked 
> (indirectly) by a Chef run?  In this specific case the code is executing in 
> a RubyGems pre-install hook.
>
> Semi-relatedly, Chef seems strongly aimed at being run to configure the 
> machine, and then mostly not run again on the same node except to add more 
> software.  For example, there aren't a lot of uninstall-based resources, I 
> don't see an obvious way to "reverse" a cookbook, few cookbooks seem 
> written to work incrementally or in stages, etc.  Is that pretty much how 
> it's intended, or am I missing something?
>
> To be fair, I haven't come up with a good scenario yet for why you'd want 
> to run it on a more continuous basis (at least, not one where you couldn't 
> do it better in some other way).  But it's odd because a lot of the 
> individual resources seem to be kind of incremental in feel (specify how 
> many backups to make, specify that you're syncing the git repository rather 
> than just creating it, etc) -- almost as though they're meant for repeated 
> use as a deployment tool, for instance.  But the cookbooks don't seem to be 
> written the same way.  It's slightly confusing.
Charles, already covered the second part a little bit but my solution
is to track those types of undo changes in a data bag. For instance,
for users, I have a deleted_users databag that is used as part of my
user management cookbook:
- Search users and deleted users data bags.
- prune any users in deleted users from users
- run the standard user management tasks in the recipes
- delete any users in the deleted users data bag

Realize that regardless of state of the system, over the course of a
few runs, any users who shouldnt be there (that chef is aware of) will
get removed. Eventually the system will converge in the way you want.
Now that strategy works for users but not, directly, for role changes.
While I have had to deal with it yet, my strategy is essentially to
manage that via via a transient role that removes itself at the end.
Assume I want to change a system from role[mysql] to role[pgsql]:

- Add role[uninstall_mysql] to the system.
- Have a mysql::uninstall recipe that, when it sees a system has a
role of uninstall_mysql, it removes and cleans up after itself.
- mysql::uninstall then removes the role uninstall_mysql from the node.

The benefit is you can do things like "backup all the database before
uninstalling" as part of that recipe. Yes, you have to manage some of
the idempotence yourself but that will be the case regardless of the
tool if it doesn't track those types of state changes.

But honestly the best approach is a "kick it/not fix it"* one. If you
have all of the recipes that can get you to role B from bare metal,
why spend the time rolling all the logic into a special recipe? Just
kick the node from scratch with role A.

* http://goo.gl/bfE8s

John E. Vincent
http://about.me/lusis