Files

Alex Schultz 48e0ef86bf Update docs structure

The upstream docs structure is changing, so this change updates our
existing docs into contributor and install guide sections.

Change-Id: I70bd519f3be74513a5f99f7b94719d7c07424a5b
Depends-On: Ia750cb049c0f53a234ea70ce1f2bbbb7a2aa9454

2017-06-23 15:41:33 -06:00

3.1 KiB

Raw Blame History

Coding Style

Note

this document is a work in progress and the content will evolve. Any contribution is welcome though ;-)

Read this page
Make sure that what you're going to code is not already a work in progress
Make sure you're familiar with Puppet Syntax, Lint, Rspec and Beaker
If you want to create a new module, read New Module.

Best practices

Deprecation

Any patch must be backward compatible.

It meansː

do not break the interface (deprecate parameters for at least one cycle, and add a warning for our users)
do not change default parameters (except if you have a good reason but your commit message must explain it)

Commit message

Please read GitCommitMessages

Consistency

We have a lot of modules to maintain, please keep our code consistent. Before adding new parameters or new classes, see if other modules already implement them and keep consistent. See also our common libraries OpenStackLib

Config file defaults and parameters

We want users that don't override a value to get the default for the service being configured. Many of the parameters passed in to classes and defined types translate directly into a config file setting. When a parameter translates directly to a config file value, and the value is optional, it should be set to $::os_service_default. This is a special value that will ensure that the service default is used by removing any existing value from the config file.

Empty parameters

When you need to specify an empty (nil) parameter, using undef is the best choice. Do not useː " (not Puppetish) or false (undef is false if tested as a boolean).

Testing

Everything about testing you can find here.

Documentation

Validate all parameters are documented. They are required and lint will check it.
If possible, keep examples/*.pp updated, they are very useful for our users.
Comment your code when needed (temporary workarounds, TODO, etc).

Asking for review

Different ways to get reviewsː

Go on IRC #puppet-openstack (freenode) and gently ask for reviews. If you need to discuss about already reviewed code, you can ping the reviewers.
Add your patch on the Puppet OpenStack meeting Agenda (in Open Discussion section).
Use the Mailing list.

3.1 KiB Raw Blame History Unescape Escape