[chef] Re: Re: Rationale behind deployment callbacks / hooks


Chronological Thread 
  • From: Loïc Antoine-Gombeaud < >
  • To:
  • Subject: [chef] Re: Re: Rationale behind deployment callbacks / hooks
  • Date: Fri, 25 Jan 2013 13:05:27 +0100

That's really interesting, thank you for your answer. I'm going to digress here, but you've made me even more curious: is it common for open-source projects to implement features that benefit one user / group of users' requirements, but not necessarily all of them? How is that decision made: is it a conscious, group-approved decision, or does it just "happen"?

I'm at the very beginning of my career and have never dabbled in open-source before, I must say I'm quite impressed by what a community of people scattered around the world can achieve, even knowing that there is often a core of developers based in the same physical place. 

What would be a good reference for getting to know those work mechanisms better?

On Thu, Jan 24, 2013 at 5:09 PM, Daniel DeLeo < " target="_blank"> > wrote:

On Thursday, January 24, 2013 at 6:42 AM, Loïc Antoine-Gombeaud wrote:

Hi chefs,

can somebody explain the rationale behind deployment callbacks, also called deployment hooks [1]? More precisely, I understand their purpose quite well (and use them myself), however I don't understand why they should be stored in the application code base instead of inside the cookbooks. 
According to Scalarium documentation [2], it is an inherited Capistrano behaviour, but that doesn't answer the question of location AFAICT.

The reasons I'm asking are the following:
- it's a pain to maintain deployment code in two distinct repositories, and
- I'm just curious :)
The deploy resource is a port of an earlier project that provided Capistrano-style deployment for Chef, developed and used at Engine Yard, and the intention was to provide compatibility with that implementation. You can imagine that in an Engine Yard type scenario, you may be able to fill in all the parameters to the deploy resource from information you have in a database or with sane defaults for your environment, while allowing some custom functionality via hooks that live in the code repo.

If you don't want to keep the callback code separate, you can just give blocks of Chef code to the callbacks instead of looking up the files.
-- 
Daniel DeLeo




--
Loic ANTOINE-GOMBEAUD
IT contact & DevOps Engineer

 
Plinga GmbH | Saarbrücker Straße 20/21 | 10405 Berlin | Germany
E-Mail:  " target="_blank">  | skype: loic.plinga
Cell: +49 (0) 160 922 86573

www.plinga.com

Geschäftsführer: Johannes Kreibohm, Florian Schmidt-Amelung
Eingetragen beim Amtsgericht Charlottenburg, HRB 119994



Archive powered by MHonArc 2.6.16.

§