Talk:Puppet/Coding and style guidelines

2013

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)

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)

When should we use a role?

hashar (talk) Whenever you have WMF specific parameters.

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)

---

Ferm rules

@Muehlenhoff: Could you please add some guidance about where ferm rules & Co. should be located, etc.? --Tim Landscheidt (talk) 14:13, 10 March 2016 (UTC)

Supported Puppet version(s)

It should be clarified which Puppet version is/versions are actually in use and thus must be conformed to by manifests & Co. --Tim Landscheidt (talk) 06:21, 27 December 2016 (UTC)

You are right; I guess we should aim at having all new code to be valid in puppet 4.x, and move quickly to the future parser in 3.8 at least. Giuseppe Lavagetto (talk) 10:44, 2 January 2017 (UTC)

Note that in Labs, Precise instances (for about three more months) are at 3.4.3-1~ubuntu12.04.1 while Trusty instances install Ubuntu's 3.4.3-1ubuntu1.1 and not apt.wikimedia.org's 3.8.5-2~bpo8trusty+2 (this seems to be due to a) Puppet being installed before the apt configuration is in place and b) base::puppet having ensure => present and not ensure => latest). For most code, the version of the puppetmaster is probably the critical factor, but for agent-side stuff (custom resources?) the agent's version can be limiting as well. --Tim Landscheidt (talk) 12:09, 2 January 2017 (UTC)

questions on organization and best practice

I think this model is much better and I appreciate the work that has gone into it greatly (so thank you!). A few things I'm confused on (which may be overlapping) while trying to understand for my own purposes:

1) ‘base’ is a profile included in the standard module which seems to violate the module/profile/role idiom. This seems backwards from the guidelines?

2) ‘include standard’ in a (new style) role seems not ordered so any further profile dependent would be in jeopardy of race condition? I'm wondering if we avoid this currently with standard applied first on new server installs and are setting ourselves up for trouble on re-installs down the road. I think the answer here is we don't want cross-profile dependency outside of limited explicit 'require' usage but a foundation of a 'standard' or 'base' as an expected first state seems possibly reasonable outside of that. The alternative seems to scattered require's around the profile tree. Should a profile 'standard' which has a parameterized class declaration of a 'base' be a 'require' at the top of every role?

2.5) ‘include standard’ in roles seems to violate the module/profile/role idiom. Is this a temporary measure or a magic I’m not understanding? Mainly my confusion is that 'include standard' is in the role where it can’t be parameterized as an include but it needs to be parameterized to fix explicit base/standard hiera applications?

An example of carried over implicit param to something that otherwise looks new format:

   role/common/elasticsearch/relforge.yaml
   profile::base::check_disk_options: -w 18% -c 15% -l -e -A -i "/srv/sd[a-b][1-3]" --exclude-type=tracefs

3) Docs indicate to include the the system::role line in the profile but I can only find one example of this. Should there be a system::profile and a system::role? I think either no one is reading and following this guideline or the docs are mixed up. I would vote to establish system::profile, keeping system::role (in the new style outline) under the profile module is misleading.

   If needed, any system::role definition should go in profiles.

4) Docs indicate not to use “fallbacks”. Does this mean no defaults on profile hiera lookups? Looking at ‘profile::etcd’ as a canonical example I see

   $cluster_bootstrap = hiera('profile::etcd::cluster_bootstrap', false). 

is this in violation? Not asking to be pedantic, but I'm unsure if "fallback" and "profile class param default" are the same thing.

5) Where is the appropriate place for the application of 'base::firewall'? I see it in a few profiles such as "profile/manifests/gerrit/server.pp" which could be OK but it's not consistent (it is also only "class {'base::firewall:'}" style in 2 of 21 places meaning most new style profiles are not correct even if this is the right place).

Sometimes it appears in the (new style) roles as an include for the module itself:

   class role::docker::registry {
       include ::standard
       include ::base::firewall
   }

Which seems to be in violation of the intended pattern? This would be helpful for me to make explicit on our documentation page as there are still instances of "standard" and "base::firewall" under the node definitions in site.pp (aside from new style use inconsistency) and I'm not sure where to move it in the official sense.

Rush (talk) 14:39, 19 July 2017 (UTC)

Moving this under Puppet and splitting up the content

This article's getting pretty big and seems to cover multiple items. I propose splitting up the articles into sub-pages under Puppet:

• Puppet/Coding and style guidelines (containing current "Organization", "Coding style", the various editor guideline sections, and "Puppet modules" sections)
• Puppet/Local environment (containing current "Set up local environment", "Testing a patch" sections)
• Puppet/Troubleshooting (containing the "Common errors" section)

--BCornwall (talk) 17:52, 3 June 2022 (UTC)

Sorry missed this, but SGTM Jbond (talk) 12:48, 13 June 2022 (UTC)

Done I didn't create Puppet/Troubleshooting as I didn't really see enough content to justify a new article --BCornwall (talk) 17:19, 30 June 2022 (UTC)