CONTRIBUTING.markdown

   1 # Contributing to the OpenDaylight Puppet Module
   2
   3 We work to make contributing easy. Please let us know if you spot something we can do better.
   4
   5 #### Table of Contents
   6 1. [Overview](#overview)
   7 1. [Communication](#communication)
   8     * [Issues](#issues)
   9     * [Gitter](#gitter)
  10 1. [Patches](#patches)
  11 1. [Testing](#testing)
  12     * [Test Dependencies](#test-dependencies)
  13     * [Syntax and Style Tests](#syntax-and-style-tests)
  14     * [Unit Tests](#unit-tests)
  15     * [System Tests](#system-tests)
  16     * [Tests in Continuous Integration](#tests-in-continuous-integration)
  17
  18 ## Overview
  19
  20 We use [GitHub Issues](https://github.com/dfarrell07/puppet-opendaylight/issues) for most communication, including bug reports, feature requests and questions.
  21
  22 We accept patches via [GitHub Pull Requests](https://github.com/dfarrell07/puppet-opendaylight/pulls). Please fork our repo, make your changes, commit them to a feature branch and *submit a PR to have it merged back into this project*. We'll give feedback and get it merged ASAP.
  23
  24 ## Communication
  25
  26 *Please use public, documented communication instead of reaching out to developers 1-1.*
  27
  28 Open Source projects benefit from always communicating in the open. Previously answered questions end up becoming documentation for other people hitting similar issues. More eyes may get your question answered faster. Doing everything in the open keeps community members on an equal playing field (`@<respected company>` email addresses don't get priority, good questions do).
  29
  30 We prefer [Issues](https://github.com/dfarrell07/puppet-opendaylight/issues) for most communication.
  31
  32 ### Issues
  33
  34 Please use our [GitHub Issues](https://github.com/dfarrell07/puppet-opendaylight/issues) freely, even for small things! They are the primary method by which we track what's going on in the project.
  35
  36 The labels assigned to an issue can tell you important things about it.
  37
  38 For example, issues tagged [`good-for-beginners`](https://github.com/dfarrell07/puppet-opendaylight/labels/good-for-beginners) are likely to not require much background knowledge and be fairly self-contained, perfect for people new to the project who are looking to get involved.
  39
  40 The priority-related issue labels ([`prio:high`](https://github.com/dfarrell07/puppet-opendaylight/labels/prio%3Ahigh), [`piro:normal`](https://github.com/dfarrell07/puppet-opendaylight/labels/prio%3Anormal)...) are also important to note. They typically accurately reflect the next TODOs the community will complete.
  41
  42 The `info:progress` labels may not always be up-to-date, but will be used when appropriate (typically long-standing issues that take multiple commits).
  43
  44 Issues can be referenced and manipulated from git commit messages. Just referencing the issue's number (`#42`) will link the commit and issue. Issues can also be closed from commit messages with `closes #42` (and [a variety of other key words](https://help.github.com/articles/closing-issues-via-commit-messages/)).
  45
  46 ### Gitter
  47
  48 We're experimenting with Gitter, a GitHub-driven chat service that works on a per-repo basis.
  49
  50 Feel free to hop in [our room](https://gitter.im/dfarrell07/puppet-opendaylight) and test it out with us.
  51
  52 ## Patches
  53
  54 Please use [Pull Requests](https://github.com/dfarrell07/puppet-opendaylight/pulls) to submit patches.
  55
  56 Basics of a pull request:
  57 * Use the GitHub web UI to fork our repo.
  58 * Clone your fork to your local system.
  59 * Make your changes.
  60 * Commit your changes, using a [good commit message](http://chris.beams.io/posts/git-commit/) and referencing any applicable issues.
  61 * Push your commit.
  62 * Submit a pull request against the project, again using GitHub's web UI.
  63 * We'll give feedback and get your changed merged ASAP.
  64 * You contributed! [Thank you](http://cdn3.volusion.com/74gtv.tjme9/v/vspfiles/photos/Delicious%20Dozen-1.jpg)!
  65
  66 Other tips for submitting excellent pull requests:
  67 * If you'd like to make more than one logically distinct change, please submit them as different pull requests (if they don't depend on each other) or different commits in the same PR (if they do).
  68 * If your PR contains a number of commits that provide one logical change, please squash them using `git rebase`.
  69 * Please provide test coverage for your changes.
  70 * If applicable, please provide documentation updates to reflect your changes.
  71
  72 ## Testing
  73
  74 ### Test Dependencies
  75
  76 The testing tools have a number of dependencies. We use [Bundler](http://bundler.io/) to make installing them easy.
  77
  78 ```
  79 [~/puppet-opendaylight]$ bundle install
  80 ```
  81
  82 ### Syntax and Style Tests
  83
  84 We use [Puppet Lint](http://puppet-lint.com/) and [Puppet Syntax](https://github.com/gds-operations/puppet-syntax) to validate the module's syntax and style.
  85
  86 ```
  87 [~/puppet-opendaylight]$ bundle exec rake lint
  88 [~/puppet-opendaylight]$ bundle exec rake syntax
  89 ```
  90
  91 ### Unit Tests
  92
  93 We use rspec-puppet to provide unit test coverage.
  94
  95 To run the unit tests and generate a coverage report, use:
  96
  97 ```
  98 [~/puppet-opendaylight]$ bundle exec rake spec
  99 # Snip test output
 100 Finished in 10.08 seconds (files took 0.50776 seconds to load)
 101 537 examples, 0 failures
 102
 103
 104 Total resources:   19
 105 Touched resources: 19
 106 Resource coverage: 100.00%
 107 ```
 108
 109 Note that we have a very large number of tests and 100% test coverage.
 110
 111 To run the syntax, style and unit tests in one rake task (recommended), use:
 112
 113 ```
 114 [~/puppet-opendaylight]$ bundle exec rake test
 115 ```
 116
 117 ### System Tests
 118
 119 While the [unit tests](#unit-tests) are able to quickly find many errors, they don't do much more than checking that the code compiles to a given state. To verify that the Puppet module behaves as desired once applied to a real, running system, we use [Beaker](https://github.com/puppetlabs/beaker).
 120
 121 Beaker stands up virtual machines using Vagrant, applies the OpenDaylight Puppet module with various combinations of params and uses [Serverspec](http://serverspec.org/resource_types.html) to validate the resulting system state.
 122
 123 To run our Beaker test against the primary target OS (CentOS 7) using the recommended RPM-based install method:
 124
 125 ```
 126 [~/puppet-opendaylight]$ bundle exec rake beaker
 127 ```
 128
 129 The `RS_SET` environment variable can be use to change Beaker's target OS (Fedora 20, Fedora 21, CentOS 7, Ubuntu 14.04). ODL's install method (RPM or tarball) can be configured via the `INSTALL_METHOD` environment variable.
 130
 131 ```
 132 [~/puppet-opendaylight]$ RS_SET=fedora-20 INSTALL_METHOD=tarball bundle exec rake beaker
 133 ```
 134
 135 There are a number of pre-defined rake tasks to simplify running common Beaker tests.
 136
 137 ```
 138 [~/puppet-opendaylight]$ bundle exec rake centos
 139 [~/puppet-opendaylight]$ bundle exec rake centos_tarball
 140 [~/puppet-opendaylight]$ bundle exec rake fedora_20
 141 [~/puppet-opendaylight]$ bundle exec rake fedora_21
 142 [~/puppet-opendaylight]$ bundle exec rake ubuntu
 143 ```
 144
 145 If you'd like to preserve the Beaker VM after a test run, perhaps for manual inspection or a quicker follow-up test run, use the `BEAKER_destroy` environment variable.
 146
 147 ```
 148 [~/puppet-opendaylight]$ BEAKER_destroy=no bundle exec rake centos
 149 ```
 150
 151 You can then connect to the VM by navigating to the directory that contains its Vagrantfile and using standard Vagrant commands.
 152
 153
 154 ```
 155 [~/puppet-opendaylight]$ cd .vagrant/beaker_vagrant_files/centos-7.yml
 156 [~/puppet-opendaylight/.vagrant/beaker_vagrant_files/centos-7.yml]$ vagrant status
 157 Current machine states:
 158
 159 centos-7                  running (virtualbox)
 160 [~/puppet-opendaylight/.vagrant/beaker_vagrant_files/centos-7.yml]$ vagrant ssh
 161 [vagrant@centos-7 ~]$ sudo systemctl status opendaylight
 162 opendaylight.service - OpenDaylight SDN Controller
 163    Loaded: loaded (/usr/lib/systemd/system/opendaylight.service; enabled)
 164    Active: active (running) since Fri 2015-04-24 16:34:07 UTC; 1min 1s ago
 165      Docs: https://wiki.opendaylight.org/view/Main_Page
 166            http://www.opendaylight.org/
 167 [vagrant@centos-7 ~]$ logout
 168 [~/puppet-opendaylight/.vagrant/beaker_vagrant_files/centos-7.yml]$ vagrant destroy -f
 169 ```
 170
 171 For more information about using Beaker, see [these docs](https://github.com/puppetlabs/beaker/wiki/How-to-Write-a-Beaker-Test-for-a-Module#typical-workflow).
 172
 173 ### Tests in Continuous Integration
 174
 175 We use [Travis CI](https://travis-ci.org/dfarrell07/puppet-opendaylight) to run our unit, syntax and style tests against a matrix of supported Ruby and Puppet versions at every commit. This currently results in >8500 automated tests per commit.