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

[Noah Kantrowitz < >]

On a mobile keyboard so can't write as much as I would like, but this is fundamentally the wrong way to model app deployment with chef. Chef is a convergent system and so you need to thnk in terms of convergent units, not procedural steps like you have there. If you need additional procedural orchestration on top of the convergent bits, and you usually will,  there are great tools for that like Fabric, Rundeck, or Opscode's own push jobs. These two pieces work together to manage deployments, chef converges state, fabric (et al) orchestrates procedural steps.

--Noah

On June 18, 2014 at 12:10:03 AM PDT, Florian Hehlen < > wrote:

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.