On 07/05/2013 02:46 PM, David Schmitt wrote: > One of the big arguments for puppet is the unifying aspect of devs and > ops to use the same tool/language/process, which improves cooperation, > agility and quality of the work. This indicates that your application > deployment should be integrated into your puppet manifests and those > manifests should be integrated into the application development/release > cycle.
But how are they integrated in your environment? What would you do in my case? > Another big point in puppet's favor is that it doesn't want to be the > be-all-end-all. If there's a tool that is better suited to a task (the > prime example being package managers) then *please* use that. This > indicates that if capistrano is a good match for your organization's > application deployment (especially in the area of orchestration across > nodes and rollback it leaves puppet in the dust), then you should > leverage those capabilities. And that's exactly why are we using another tool for the job. > You write "this poses a problem for me, because I'm used to manage > configuration files via puppet." While that may just be lost in > translation, it does sound like your problem is of a much more personal > and a less technical level. > In that case you really need to get rid of > the us-against-them attitude and find solutions that enable the > organization as a whole to repeatably deliver more value faster while > reducing the associated risks. 'you need to find solutions' is a thing I already now. If I didn't know that, I wouldn't have asked the question in the first place. On the other hand, one thing I didn't ask about was online psychotherapy... Did I offend you some how with my OP? If I did, I'm really sorry, that was not my intention. > This is a non-issue as the deployment process will always be able to > push the changes it needs into the system. So a subversion (no pun > intended) of the deployment process will always be a death knell, > independent of the used tool. So either the devs have the need and right > to modify those configuration files, or they don't. If they have the > need and right, then they also share the responsibility for the system. Yeah, but things have to stay pretty tight. For example: if you enable some user account to push files into dot-d directory, not-if-but-when that account gets broken into, you have a possibility of privilege escalation. So, allowing the write privilege for that directory obviously is not a good choice. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
