[chef] RE: Re: RE: Re: override argument

[Florian Hehlen < >]

Hi.

Thanks for all the feedback. What is then the general practice that people 
follow with application life-cycle management?

Imagine you have the following recipes:
- app::default (does maintenance things like rolling logs, restarting app if 
down)
- app::install
- app::upgrade
- app::patch_db
- app::backup
- app::restore
- app::clean

It makes no sense to run everything all of the time. Especially, if I am 
running chef-client every 15 minutes to monitor the node, which I don't do 
but I would like to. How do I run different combinations of these at 
different times? This is also really important in DEV or TEST environments 
where we constantly use the different combinations of recipes. At the moment 
I mostly rely on -o to do this but I have noticed that it does not always go 
as expected (which prompted this thread). So I don't use -o in prod but 
rather adjust the list of recipes on the node when I need to. This is clunky 
and dangerous I think a node's definition should be changed as rarely as 
possible.

Florian

-----Original Message-----
From: Daniel DeLeo 
[mailto:
 
 On Behalf Of Daniel DeLeo
Sent: 18 June 2014 00:14
To: 

 
Subject: [chef] Re: RE: Re: override argument



On Tuesday, June 17, 2014 at 2:26 PM, Chris Sibbitt wrote:

> Did this behavior change in Chef Client 11?

We removed the node save in a recent 11.x release.

>
>
> We're still stuck on Chef 10 and the major gotcha we face with the use of 
> -o is that all the attributes from other cookbooks disappear, disrupting 
> node searches and such, just like you say. Essentially we've found that 
> while -o might come in useful, it should generally be followed by a full 
> run ASAP to prevent the corruption of the attributes and search-based 
> relationships. As such we have structured the recipes which are generally 
> -o material for us (recipes that do destructive upgrades, for example) such 
> that they always include_recipe some top-level recipe at the end, forcing a 
> more complete run to happen as part of the -o. More restrictive use of -o 
> for "partial runs" has always caused more pain then it is worth for us.
>
> In Chef 10 all the attributes get dropped at the beginning of the run, and 
> then any new attributes from cookbooks that execute do get saved to the 
> server AFAICT. When I eventually upgrade to Chef Client 11, can I expect 
> all of my original attributes to remain unchanged after a -o run? That 
> would be awesome except for the cases where we do a node.set in the recipe 
> that is commonly used with -o....

You can manually call `node.save`, but of course that puts you back where you 
started...

--
Daniel DeLeo


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.