On Mon, Aug 6, 2012 at 5:16 PM, Michael Frank <[email protected]>wrote:
> apologies for the late reply, i was strictly AFK over the weekend :) > it's all good :) > I don't view the procedural-vs-declarative style as much of an issue. > After all, you can be very procedural in puppet with a little extra effort, > by distributing shell scripts and using the exec resource. Chef perhaps > has a bit less of a 'safety-guard', but once you start going down that > road, it just boils down to ruby scripting instead of > bash/python/whatever. Furthermore, i'll argue that at some point, every > non-trivial (read: useful) deployment is going to grow complicated enough > to drive you to script configuration in a procedural way. > yeah, I just found that trying to do procedural logic in puppet was a lot of pain. It's DSL is also a little too restrictive though I believe they allow you to go to ruby now if you want a full blown language. > Chef has a nice hierarchical abstraction of a network, with environments, > roles, and nodes, and you can insert data into these abstractions which > chef's recipes can access. This is more powerful than puppet's flat space > of classes, and also enforces a separation of data and code which makes > your recipes cleaner and more generic. > interesting. we used yaml for abstracting data away from the logic in puppet. that seemed to work ok. i have generally not ventured too deep in this area, but my gut says i > would be slightly more comfortable using puppet's declarative approach. > that is my gut talking tho, and it has similar feelings about coke over > pepsi, and red vines over twizzlers :) > I would say that if you leverage puppet's built in concepts or libraries then it works rather well but once you start having to write custom code ( especially very procedural code) you have to go down the scripting route and try not to do it all in puppet. cheers, -- Nimret Sandhu http://www.nimret.org
