Noah,
I see your point. I am not sure I agree though. You seem to have a view that state convergence stops at a certain point. I think the only recipes below that
aren’t about state convergence are ‘default’ and ‘backup’. So why should I use Chef to install/upgrade an OS level package, or a database, or a JVM but not to install/upgrade my application?
One way out of my problem is to have logical switches, activated through attributes, which will cause certain recipes to happen only during certain runs.
That just seems a bit clunky and error-prone when some of the actions should only be done in very special cases.
I also find that Chef provides all the paradigms I need for managing an application’s life-cycle. Why add one more layer of indirection with Fabric, Rundeck,
etal?
Florian
From: Noah Kantrowitz [mailto:
Sent: 18 June 2014 09:17
To:
Subject: [chef] RE: Re: RE: Re: override argument
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.
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.
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.