On Friday, January 25, 2013 at 10:05, Loïc Antoine-Gombeaud wrote: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"?That's a very general question. Open Source software can be anything whose source anyone has opened to the world.Sometimes it's Wordpress, sometimes it's a bash script to bootstrap my Unix user. The former is built thinking about all the users, the latter is built for myself. The reason why I might open my own scripts is that other people might benefit from what I did in some way -- learning, applying similar design decisions, etc. Many people think of FOSS (Free and Open Source Software) as something that someone created to "scratch their own itch", and many projects do start like that.You have all sorts of shades in between those two extremes. :)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.It is certainly incredible, specially when those projects are not directly (or even indirectly) backed by a company. I'd suggest you read more about the history and current state of the Linux kernel and the Debian project. While reading about Debian, do search for their Social Contract and other guiding documentation.What would be a good reference for getting to know those work mechanisms better?Mailing lists, blogs, IRC, user groups, github, DuckDuckGo :)Look for local user groups on topics of interest and make contributions to the communities. Github is your friend. That'll send you a long way.And, of course, pub talks with fellow geeks!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.