Talk:Puppet coding
Rendered with Parsoid
Latest comment: 11 years ago by Hashar
Antoine answers to original Andrew questions:
- How does our puppet coding style differ from the upstream guide at http://docs.puppetlabs.com/guides/style_guide.html
- hashar (talk) For any new module, I enforce the upstream puppet style guide by running `puppet-lint` on the module before submitting any new change to it. For the rests, we use mostly tabs and double quotes, sometime file {} which defines several files.
- I like the idea of having it be linted, but I hate the idea of having two different styles (which, for one thing, makes linting close to impossible.) So, we probably have to bikeshed this and actually agree on a standard. andrew (talk) 19:56, 15 March 2013 (UTC)
- I would lint existing manifests as we migrate them to modules :-] Respecting the upstream standard seems worthwhile to me. hashar (talk) 21:33, 15 March 2013 (UTC)
- I like the idea of having it be linted, but I hate the idea of having two different styles (which, for one thing, makes linting close to impossible.) So, we probably have to bikeshed this and actually agree on a standard. andrew (talk) 19:56, 15 March 2013 (UTC)
- What kind of things should we use puppet for and what kind of things shouldn't we? (In labs? In production?)
- hashar (talk) Should not be used to deploy software. I use dedicated git repositories for that and git pull. Sartoris might eventually one day let us handle that nicely.
- I need this distinction explained to me, hopefully with examples. It seems to me that /everything/ puppet is used for could be described as 'deploying'. Installing apache, adding something to sites_enabled? Sounds like deployment to me. andrew (talk) 19:56, 15 March 2013 (UTC)
- When should we use a module vs. a manifest?
- hashar (talk) Always modules. They take advantage of puppet autoloading mecanism that will let us creates unit and integration tests later on without having to load ALL the manifests via site.pp :-]
- Except for roles, which are a kind of manifest which lives in the global namespace, right? Are there any other exceptions? andrew (talk) 19:56, 15 March 2013 (UTC)
- I think the distinction isn't quite clearcut. It makes a great deal of sense (to me) to group cohesive roles that work together in a module – as much for maintainability (group related, isolate from unrelated) as it does for efficiency purposes (because modules autoload). marc 18:03, 22 April 2013 (UTC)
- Except for roles, which are a kind of manifest which lives in the global namespace, right? Are there any other exceptions? andrew (talk) 19:56, 15 March 2013 (UTC)
- Where do roles go? Inside modules or outside?
- hashar (talk) They can be made a module like `wmf_role` for now they are all as manifests in the global scope.
- Should modules be site-agnostic or can they contain WMF-specific configuration?
- Probably be made as agnostic as possible but accepting parameters that would let us apply the WMF specificity via a role class.
- That means, presumably, that almost every template and file will live outside of the module? Doesn't that lose us much of the organizational power of modules? andrew (talk) 19:56, 15 March 2013 (UTC)