beaker 3.35.0 → 3.36.0

data/docs/how_to/change_terminal_output_coloring.md

@@ -5,16 +5,18 @@ Beaker uses a set of colors to output different types of messages on to the term
    If you do not provide any values, the defaults are: [Default colors](https://github.com/puppetlabs/beaker/blob/master/lib/beaker/logger.rb#L85-L95)
 
 ## Beaker Color Codes:
+
 In addition, Beaker can support few other colors. List of all colors supported by Beaker:  [Colors Supported by Beaker] (https://github.com/puppetlabs/beaker/blob/master/lib/beaker/logger.rb#L14-L32)
 
 ## How to Customize:
+
 Changes to the default options can be made by editing the configuration file.
 
 Here are some examples:
 
-**Eg 1: Changing color of a particular type of message**
-Add the following to the hosts file to change the color of `success` messages to `GREEN` and `warning` messages to `YELLOW`.
-To get the color-code corresponding to a color, refer to: [Colors Supported by Beaker] (https://github.com/puppetlabs/beaker/blob/master/lib/beaker/logger.rb#L14-L32)
+**Ex 1: Changing color of a particular type of message**
+
+Add the following to the hosts file to change the color of `success` messages to `GREEN` and `warning` messages to `YELLOW`. To get the color-code corresponding to a color, refer to: [Colors Supported by Beaker] (https://github.com/puppetlabs/beaker/blob/master/lib/beaker/logger.rb#L14-L32)
 
       HOSTS:
         ...
@@ -23,7 +25,8 @@ To get the color-code corresponding to a color, refer to: [Colors Supported by B
           success: "\e[01;35m"
           warn: "\e[00;33m"
 
-**Eg 2: Turning off colors.**
+**Ex 2: Turning off colors.**
+
 The following option in the hosts file will print the whole output in one single color.
 
       HOSTS:

data/docs/how_to/confine.md

@@ -2,10 +2,7 @@
 
 ## How does it work?
 
-The confine method will limit the hosts the testcase is run against. You can pass in either :to or :except
-to control how the criteria is applied (**:to** will apply the criteria to the hosts in order to find a match,
-**:except** will apply the criteria to the hosts, and return those hosts that do not match). The default behaviour
-is that the **TestCase#hosts** array is modified to only contain the hosts that match (or don't match) the criteria.
+The confine method will limit the hosts the testcase is run against. You can pass in either :to or :except to control how the criteria is applied (**:to** will apply the criteria to the hosts in order to find a match, **:except** will apply the criteria to the hosts, and return those hosts that do not match). The default behaviour is that the **TestCase#hosts** array is modified to only contain the hosts that match (or don't match) the criteria.
 
 Full method documentation here:
 
@@ -13,10 +10,7 @@ Full method documentation here:
 
 ## How does the optional Array<Host> parameter work?
 
-However, if you pass in the optional Array<Host> to the method, the criteria will be applied to this hosts array
-(not **TestCase#hosts**). Subsequently, any of the hosts contained in **TestCase#hosts** that were not included in the Array<Host>
-passed to the method, will remain in **TestCase#hosts**. But any hosts that were filtered out by the criteria match
-will be overwritten.
+However, if you pass in the optional Array<Host> to the method, the criteria will be applied to this hosts array (not **TestCase#hosts**). Subsequently, any of the hosts contained in **TestCase#hosts** that were not included in the Array<Host> passed to the method, will remain in **TestCase#hosts**. But any hosts that were filtered out by the criteria match will be overwritten.
 
 Take the following example:
 
@@ -52,20 +46,15 @@ Using the following confine:
 
 We will end up with a **TestCase#hosts** array with two hosts, one agent and one master.
 
-Since we passed in the 'agents' host array to the method, the criteria (:platform => 'el-7-x86_64') will be applied
-to this set of hosts. Only one agent matches this criteria (centos7_agent). Since the master host (ubuntu_master) was not
-included in the 'agents' host array when the criteria match was performed, it will remain in **TestCase#hosts**. But only one agent
-remains after the criteria match.
+Since we passed in the 'agents' host array to the method, the criteria (:platform => 'el-7-x86_64') will be applied to this set of hosts. Only one agent matches this criteria (centos7_agent). Since the master host (ubuntu_master) was not included in the 'agents' host array when the criteria match was performed, it will remain in **TestCase#hosts**. But only one agent remains after the criteria match.
 
 `confine :except, { :platform => 'el-7-x86_64' }, agents`
 
-Will also return two hosts, one agent and one master. But it will be the other agent (ubuntu_agent) as its platform does not match
-'el-7-x86_64'.
+Will also return two hosts, one agent and one master. But it will be the other agent (ubuntu_agent) as its platform does not match 'el-7-x86_64'.
 
 `confine :to, { :platform => 'el-7-x86_64' }`
 
-Will return one host (centos7_agent). Because no Array<Host> was passed to the confine method, the criteria match
-is being applied directly to **TestCase#hosts** (which contains all hosts).
+Will return one host (centos7_agent). Because no Array<Host> was passed to the confine method, the criteria match is being applied directly to **TestCase#hosts** (which contains all hosts).
 
 `confine :except, { :platform => 'el-7-x86_64' }`
 

data/docs/how_to/debug_beaker_tests.md

@@ -7,6 +7,7 @@ beaker includes [pry-byebug](https://github.com/deivid-rodriguez/pry-byebug), a
 [Pry](http://pryrepl.org/) is a powerful Ruby editing and debugging tool.  Beaker uses Pry runtime invocation to create a developer console.
 
 ### What is byebug?
+
 [Byebug](https://github.com/deivid-rodriguez/byebug) is a powerful debugger for ruby. It allows for flexible control of breakpoints, stepping through lines or the call stack. It lacks some features of pry such as source code editing and replaying code execution from within the debugging session, but can be used in combination with pry.
 
 There are several ways to have your tests break and enter debugging:
@@ -17,11 +18,12 @@ There are several ways to have your tests break and enter debugging:
 
 ## Add a breakpoint to your test file
 
-Add Pry to individual tests by adding `require 'pry'` to the Ruby test file.
-Then add the statement `binding.pry` at the point in code where you want access to the full, current Beaker environment.
+Add Pry to individual tests by adding `require 'pry'` to the Ruby test file. Then add the statement `binding.pry` at the point in code where you want access to the full, current Beaker environment.
 
 ### Example
+
 #### Example test trypry.rb
+
 Here's a test file that exercises different ways of running commands on Beaker hosts.  At the end of the main `hosts.each` loop I've included `binding.pry` to invoke the console.
 
 ```
@@ -49,6 +51,7 @@ end
 ```
 
 #### Sample output to the first `binding.pry` call:
+
 ```
 $ bundle exec beaker --tests tests/trypry.rb --hosts configs/fusion/winfusion.cfg --no-provision
 {
@@ -128,7 +131,9 @@ From: /Users/anode/beaker/tests/trypry.rb @ line 19 self.run_test:
 
 [1] pry(#<Beaker::TestCase>)>
 ```
+
 #### Using the console
+
 At this point I have access to the console.  I have full access to Beaker hosts, the Beaker DSL and Ruby.
 
 Here's some sample console calls:
@@ -216,8 +221,11 @@ w2k8r2 executed in 0.08 seconds
 [5] pry(#<Beaker::TestCase>)> result.stdout.chomp
 => "Application Data\nDesktop\nDocuments\nFavorites\nMicrosoft\nPackage Cache\nStart Menu\nTemplates\nVMware\nbeaker.gemspec\nntuser.pol"
 ```
+
 #### Continue regular test execution
+
 Simply `exit` the console.
+
 ```
 [6] pry(#<Beaker::TestCase>)> exit
 ```
@@ -239,11 +247,9 @@ Consider this example test case _test.rb_, which is going to fail:
       assert_equal(important_expected_value, actual_value, 'This product is faulty')
     end
 
-You can run this test using `beaker -t test.rb` or (to use the `run` subcommand and just run the test and bypass host provisioning etc) `beaker run -t test.rb`
-It fails.
+You can run this test using `beaker -t test.rb` or (to use the `run` subcommand and just run the test and bypass host provisioning etc) `beaker run -t test.rb`. It fails.
 
-Now try `beaker run -t test.rb --debug-errors`
-This will enter a pry console when the failure occurs.
+Now try `beaker run -t test.rb --debug-errors` This will enter a pry console when the failure occurs.
 
     * Assert expected matches actual
       Exception raised during step execution and debug-errors option is set, entering pry. Exception was: #<Minitest::Assertion: This product is faulty.
@@ -305,11 +311,13 @@ The arrow indicates pry is showing code at the top of the stack trace. At positi
 From here, you can examine variables in your test. If you have hosts provisioned, you can send them commands using the [on](http://www.rubydoc.info/github/puppetlabs/beaker/Beaker/DSL/Helpers/HostHelpers#on-instance_method) method, or in a separate terminal ssh into them to investigate their state at the point of failure.
 
 ## Defining external breakpoints with byebug
+
 This method is perhaps the least intuitive to use; but combines the advantages of letting you pick the line(s) of code to set breakpoints on; and being able to debug without needing to edit your test code directly. It is sometimes desirable to debug a test without changing the test's code at all; for example, if you want to compare a test at two or more different git commits, your test source needs to remain unmodified from its committed form.
 
 byebug allows you to externally define breakpoints to keep them separate from your source code.
 
 ### Example
+
 Consider the following test file test.rb:
 
 ```ruby

data/docs/how_to/hosts/README.md

@@ -1,8 +1,5 @@
 # The Hosts Directory
 
-This directory contains docs explaining any peculiarities or details of a particular
-OS's host implementation.
+This directory contains docs explaining any peculiarities or details of a particular OS's host implementation.
 
-If you don't see a file here for an OS, then it's either not yet documented
-(feel free to help us out here!), or it should conform to our normal host
-abstraction assumptions.
+If you don't see a file here for an OS, then it's either not yet documented (feel free to help us out here!), or it should conform to our normal host abstraction assumptions.

data/docs/how_to/hosts/archlinux.md

@@ -1,14 +1,16 @@
 # Arch Linux
 
 > Arch Linux is an independently developed, i686/x86-64 general-purpose GNU/Linux distribution that strives to provide the latest stable versions of most software by following a rolling-release model. The default installation is a minimal base system, configured by the user to only add what is purposely required.
-**Source: https://wiki.archlinux.org/index.php/Arch_Linux**
+
+Source: https://wiki.archlinux.org/index.php/Arch_Linux
 
 # Installation
 
 ## Specifying a version to install
 
 > Arch Linux strives to maintain the latest stable release versions of its software as long as systemic package breakage can be reasonably avoided.
-**Source: https://wiki.archlinux.org/index.php/Arch_Linux**
+
+Source: https://wiki.archlinux.org/index.php/Arch_Linux
 
 Since Arch is a rolling release, the Puppet version installed by Pacman will always be the latest avaliable release from the upstream.
 

data/docs/how_to/hosts/cisco.md

@@ -1,36 +1,23 @@
 # Wind River Linux
 
-Wind River Linux is an embedded systems OS from Wind, an Intel Company.  You
-can get more details on this from their
-[product page](http://www.windriver.com/products/linux/).
+Wind River Linux is an embedded systems OS from Wind, an Intel Company.  You can get more details on this from their [product page](http://www.windriver.com/products/linux/).
 
-Beaker provides support for 2 of Cisco's Wind River Linux platforms.
-Those platform codenames are `cisco_nexus` for Cisco NX-OS based systems
-and `cisco_ios_xr` for Cisco IOS XR based systems.
+Beaker provides support for 2 of Cisco's Wind River Linux platforms. Those platform codenames are `cisco_nexus` for Cisco NX-OS based systems and `cisco_ios_xr` for Cisco IOS XR based systems.
 
 Beaker currently can install puppet on Cisco Nexus and Cisco IOS XR.
 
 # Host Requirements
 
-WRLinux hosts validate their setup once created, and will fail if not
-setup correctly.  There are two conditions that are validated specifically
-on WRLinux hosts.  These conditions are listed below.
+WRLinux hosts validate their setup once created, and will fail if not setup correctly.  There are two conditions that are validated specifically on WRLinux hosts.  These conditions are listed below.
 
-A. All Cisco Nexus hosts will need a `:vrf` value, which determines their
-virtual routing framework for networking purposes.  For our purposes,
-we tend to use the value `management`, so there is always a hosts
-file line that looks like this in our configuration:
+A. All Cisco Nexus hosts will need a `:vrf` value, which determines their virtual routing framework for networking purposes.  For our purposes, we tend to use the value `management`, so there is always a hosts file line that looks like this in our configuration:
 
     HOSTS:
       <hostname>:
         ...
         vrf: management
 
-B. All Cisco hosts will also require a user to be set on the
-hosts.  This is because they don't allow ssh'ing as the root user,
-which is one of the main assumptions that Beaker operates under in
-the usual case.  In order to specify a user to ssh with, add this
-block to a host:
+B. All Cisco hosts will also require a user to be set on the hosts. This is because they don't allow ssh'ing as the root user, which is one of the main assumptions that Beaker operates under in the usual case. In order to specify a user to ssh with, add this block to a host:
 
     HOSTS:
       <hostname>:
@@ -40,22 +27,14 @@ block to a host:
 
 # Hypervisors
 
-WRLinux has only been developed and tested as a
-[vmpooler](https://github.com/puppetlabs/vmpooler) host.
+WRLinux has only been developed and tested as a [vmpooler](https://github.com/puppetlabs/vmpooler) host.
 
-This doesn't mean that it can't be used in another hypervisor, but that
-Beaker doesn't specifically deal with the details of that hypervisor in creating
-WRLinux hosts, if there is anything specific to WRLinux that will need to be done in
-provisioning steps.
+This doesn't mean that it can't be used in another hypervisor, but that Beaker doesn't specifically deal with the details of that hypervisor in creating WRLinux hosts, if there is anything specific to WRLinux that will need to be done in provisioning steps.
 
 # Installation Methods
 
 ## Open Source
 
-In order to install a puppet-agent against a WRLinux host, you'll have to use the
-[`install_puppet_agent_on`](blob/master/lib/beaker/dsl/install_utils/foss_utils.rb#L327)
-method.
+In order to install a puppet-agent against a WRLinux host, you'll have to use the [`install_puppet_agent_on`](blob/master/lib/beaker/dsl/install_utils/foss_utils.rb#L327) method.
 
-It reaches out to the WRLinux-specific host code for any information that it needs.
-You can check out [these methods](blob/master/lib/beaker/host/cisco.rb) if you
-need more information about this.
+It reaches out to the WRLinux-specific host code for any information that it needs. You can check out [these methods](blob/master/lib/beaker/host/cisco.rb) if you need more information about this.

data/docs/how_to/hosts/eos.md

@@ -1,17 +1,12 @@
 # EOS - Arista
 
-EOS is the network device OS from Arista. You can get more details from their
-[product page](https://www.arista.com/en/products/eos).
+EOS is the network device OS from Arista. You can get more details from their [product page](https://www.arista.com/en/products/eos).
 
 # Hypervisors
 
-EOS has only been developed and tested as a
-[vmpooler](https://github.com/puppetlabs/vmpooler) host.
+EOS has only been developed and tested as a [vmpooler](https://github.com/puppetlabs/vmpooler) host.
 
-This doesn't mean that it can't be used in another hypervisor, but that
-Beaker doesn't specifically deal with the details of that hypervisor in creating
-EOS hosts, if there is anything specific to EOS that will need to be done in
-provisioning steps.
+This doesn't mean that it can't be used in another hypervisor, but that Beaker doesn't specifically deal with the details of that hypervisor in creating EOS hosts, if there is anything specific to EOS that will need to be done in provisioning steps.
 
 # Installation Methods
 
@@ -21,10 +16,6 @@ provisioning steps.
 
 ## Open Source
 
-In order to install a puppet-agent against an EOS host, you'll have to use the
-[`install_puppet_agent_dev_repo_on`](blob/master/lib/beaker/dsl/install_utils/foss_utils.rb#L1085)
-method.
+In order to install a puppet-agent against an EOS host, you'll have to use the [`install_puppet_agent_dev_repo_on`](blob/master/lib/beaker/dsl/install_utils/foss_utils.rb#L1085) method.
 
-It reaches out to the EOS-specific host code for any information that it needs.
-You can check out [these methods](blob/master/lib/beaker/host/eos.rb) if you
-need more information about this.
+It reaches out to the EOS-specific host code for any information that it needs. You can check out [these methods](blob/master/lib/beaker/host/eos.rb) if you need more information about this.

data/docs/how_to/hypervisors/README.md

@@ -1,26 +1,16 @@
 # The Hypervisors Directory
 
-This directory contains docs explaining any peculiarities or details of a particular
-hypervisor's implementation.
+This directory contains docs explaining any peculiarities or details of a particular hypervisor's implementation.
 
-If you don't see a file here for a hypervisor, then it's either not yet documented
-(feel free to help us out here!), or it should conform to our normal hypervisor
-assumptions.
+If you don't see a file here for a hypervisor, then it's either not yet documented (feel free to help us out here!), or it should conform to our normal hypervisor assumptions.
 
 # Credentials File
 
-Beaker uses credentials from a `.fog` file for authentication. This file came
-from using the [fog cloud services library](http://fog.io). Beaker now only uses
-fog functionality in the openstack hypervisor, but we still use the `.fog` file
-for a credentials store.
+Beaker uses credentials from a `.fog` file for authentication. This file came from using the [fog cloud services library](http://fog.io). Beaker now only uses fog functionality in the openstack hypervisor, but we still use the `.fog` file for a credentials store.
 
-By default, the file is located under the user's home directory. This helps to
-keep the credentials confidential. The path of `.fog` file can be changed by
-setting the `dot_fog` global beaker option.
+By default, the file is located under the user's home directory. This helps to keep the credentials confidential. The path of `.fog` file can be changed by setting the `dot_fog` global beaker option.
 
-The `.fog` file is written in YAML. The keys are particular to the service that
-they correspond to, and each hypervisor's documentation should include the keys
-that are needed for it. An example `.fog` file is below:
+The `.fog` file is written in YAML. The keys are particular to the service that they correspond to, and each hypervisor's documentation should include the keys that are needed for it. An example `.fog` file is below:
 
 ```yaml
 :default:
@@ -32,16 +22,9 @@ that are needed for it. An example `.fog` file is below:
 
 # External Hypervisors
 
-Puppet and its community have made several gems that support different
-hypervisors with beaker, the reason for this is that we're looking to decrease Beaker's
-dependency footprint, and hypervisors are one of the places where we can often
-increase the load across all Beaker uses to benefit a small group that uses a
-particular hypervisor.
+Puppet and its community have made several gems that support different hypervisors with beaker, the reason for this is that we're looking to decrease Beaker's dependency footprint, and hypervisors are one of the places where we can often increase the load across all Beaker uses to benefit a small group that uses a particular hypervisor.
 
-In order to offset this, we've made a listing of gems and community-supported forks
-that support other external hypervisors. Please check them out if you'd like to use
-those hypervisors, hopefully it'll save you from spending time trying to support a
-new hypervisor yourself.
+In order to offset this, we've made a listing of gems and community-supported forks that support other external hypervisors. Please check them out if you'd like to use those hypervisors, hopefully it'll save you from spending time trying to support a new hypervisor yourself.
 
 ### Hypervisor gems made by puppet (pre-included in beaker 3.x):
 
@@ -59,14 +42,9 @@ new hypervisor yourself.
 
 ### beaker-abs
 
-There is another hypervisor made and used internally by puppet,
-[beaker-abs](https://github.com/puppetlabs/beaker-abs), but it isn't included
-in beaker 3.x. If you'd like to use beaker-abs, you'll have to include it yourself.
+There is another hypervisor made and used internally by puppet, [beaker-abs](https://github.com/puppetlabs/beaker-abs), but it isn't included in beaker 3.x. If you'd like to use beaker-abs, you'll have to include it yourself.
 
-You do that by requiring beaker-abs in your Gemfile as a sibling to beaker itself
-and then using `abs` as your hypervisor value in your hosts file. Please check the
-[beaker-abs README](https://github.com/puppetlabs/beaker-abs/blob/master/README.md)
-for more information.
+You do that by requiring beaker-abs in your Gemfile as a sibling to beaker itself and then using `abs` as your hypervisor value in your hosts file. Please check the [beaker-abs README](https://github.com/puppetlabs/beaker-abs/blob/master/README.md) for more information.
 
 ### Hypervisor gems and beaker forks made by community:
 

data/docs/how_to/install_puppet.md

@@ -1,88 +1,53 @@
 # How To Install Puppet
 
-This doc will guide you through the process of installing Puppet Agent using
-beaker's DSL helpers.
+This doc will guide you through the process of installing Puppet Agent using beaker's DSL helpers.
 
-Note that this is not a complete documentation of the process, but a general
-overview. There will be specific hiccups for particular platforms and special
-cases. These are not all included at this point. The idea is that as we come
-upon them, we will now have a place to document those details, so that we can
-over time bring this to 100% completeness.
+Note that this is not a complete documentation of the process, but a general overview. There will be specific hiccups for particular platforms and special cases. These are not all included at this point. The idea is that as we come upon them, we will now have a place to document those details, so that we can over time bring this to 100% completeness.
 
 # First Things First: What Do You Want to Install?
 
-If you understand [beaker's roles](https://github.com/puppetlabs/beaker/blob/master/docs/concepts/roles_what_are_they.md)
-and just want the shortcuts to installing Open Source Puppet across your testing
-environment, then you should go to our "High Level Shortcuts" section below.
+If you understand [beaker's roles](https://github.com/puppetlabs/beaker/blob/master/docs/concepts/roles_what_are_they.md) and just want the shortcuts to installing Open Source Puppet across your testing environment, then you should go to our "High Level Shortcuts" section below.
 
-If you'd like to only install Puppet Agents, please checkout our "Puppet Agent
-Installs" section for more information.
+If you'd like to only install Puppet Agents, please checkout our "Puppet Agent Installs" section for more information.
 
 # High Level Shortcuts
 
-The
-[`install_puppet_on`](http://www.rubydoc.info/gems/beaker/Beaker/DSL/InstallUtils/FOSSUtils#install_puppet_on-instance_method)
-method is a wrapper on our installing Puppet behavior that allows you to pass in
-which hosts in particular you'd like to install Puppet on as well as specifying
-the options used yourself. Please checkout the Rubydocs linked above for more
-info on this method.
+The [`install_puppet_on`](http://www.rubydoc.info/gems/beaker/Beaker/DSL/InstallUtils/FOSSUtils#install_puppet_on-instance_method) method is a wrapper on our installing Puppet behavior that allows you to pass in which hosts in particular you'd like to install Puppet on as well as specifying the options used yourself. Please checkout the Rubydocs linked above for more info on this method.
 
-The
-[`install_puppet`](http://www.rubydoc.info/gems/beaker/Beaker/DSL/InstallUtils/FOSSUtils#install_puppet-instance_method)
-is deprecated. It's a shortcut method that just calls `install_puppet_on`
-passing the entire hosts array and global options hash. You can get the same
-using this code in your pre-suite:
+The [`install_puppet`](http://www.rubydoc.info/gems/beaker/Beaker/DSL/InstallUtils/FOSSUtils#install_puppet-instance_method) is deprecated. It's a shortcut method that just calls `install_puppet_on` passing the entire hosts array and global options hash. You can get the same using this code in your pre-suite:
 
 ```ruby
 install_puppet_on(hosts, options)
 ```
 
-Note that both of the high level methods will call the `install_puppet_agent_on`
-method to install released Puppet Agent versions for your agent Systems Under
-Test (SUTs). Please checkout our "Released Open Source Puppet Agents" section
-below for more information on this method.
+Note that both of the high level methods will call the `install_puppet_agent_on` method to install released Puppet Agent versions for your agent Systems Under Test (SUTs). Please checkout our "Released Open Source Puppet Agents" section below for more information on this method.
 
 # Puppet Agent Installs
 
-There are a number of Puppet Agents that you could be installing. There aren't
-only an ever-growing number of versions, but you can get Puppet Agent from a
-number of locations.
+There are a number of Puppet Agents that you could be installing. There aren't only an ever-growing number of versions, but you can get Puppet Agent from a number of locations.
 
-If you'd like to install the Puppet Agent that comes with your particular Puppet
-Enterprise (PE) install, then please skip to our "PE Promoted Agent Installs"
-section below.
+If you'd like to install the Puppet Agent that comes with your particular Puppet Enterprise (PE) install, then please skip to our "PE Promoted Agent Installs" section below.
 
-For our different Open Source variants, check out the sections just below, which
-differentiate between released & development Puppet Agent versions.
+For our different Open Source variants, check out the sections just below, which differentiate between released & development Puppet Agent versions.
 
 ### Released Open Source Puppet Agents
 
-To install a released version of Puppet Agent, beaker provides the
-[`install_puppet_agent_on`](http://www.rubydoc.info/gems/beaker/Beaker/DSL/InstallUtils/FOSSUtils#install_puppet_agent_on-instance_method)
-method. Please checkout the Rubydocs for more info on this method.
+To install a released version of Puppet Agent, beaker provides the [`install_puppet_agent_on`](http://www.rubydoc.info/gems/beaker/Beaker/DSL/InstallUtils/FOSSUtils#install_puppet_agent_on-instance_method) method. Please checkout the Rubydocs for more info on this method.
 
 ### Development Open Source Puppet Agents
 
-To install a development build of Puppet Agent, beaker provides the
-[`install_puppet_agent_dev_repo_on`](http://www.rubydoc.info/gems/beaker/Beaker/DSL/InstallUtils/FOSSUtils#install_puppet_agent_dev_repo_on-instance_method)
-method. Please checkout the Rubydocs for more info on this method.
+To install a development build of Puppet Agent, beaker provides the [`install_puppet_agent_dev_repo_on`](http://www.rubydoc.info/gems/beaker/Beaker/DSL/InstallUtils/FOSSUtils#install_puppet_agent_dev_repo_on-instance_method) method. Please checkout the Rubydocs for more info on this method.
 
 ### PE Promoted Agent Installs
 
-If you're using this method, then you're going to be downloading the installer
-from a URL configured like so:
+If you're using this method, then you're going to be downloading the installer from a URL configured like so:
 
 ```ruby
 http://pm.puppetlabs.com/puppet-agent/#{ pe_version }/#{ puppet_agent_version }/repos
 ```
 
-`pe_version` is a variable that you can provide using either the host or global
-property `:pe_ver`. This is usually done in the hosts file, and will default to
-`4.0.0-rc1` if nothing is specified.
+`pe_version` is a variable that you can provide using either the host or global property `:pe_ver`. This is usually done in the hosts file, and will default to `4.0.0-rc1` if nothing is specified.
 
-`puppet_agent_version` is a variable you can provide the value of through the
-same methods as `pe_version` above. It will default to `latest`.
+`puppet_agent_version` is a variable you can provide the value of through the same methods as `pe_version` above. It will default to `latest`.
 
-Beaker's DSL method to install from this location is
-[`install_puppet_agent_pe_promoted_repo_on`](http://www.rubydoc.info/github/puppetlabs/beaker/Beaker/DSL/InstallUtils/FOSSUtils#install_puppet_agent_pe_promoted_repo_on-instance_method).
-Follow the link to get API-level docs on this method for more info.
+Beaker's DSL method to install from this location is [`install_puppet_agent_pe_promoted_repo_on`](http://www.rubydoc.info/github/puppetlabs/beaker/Beaker/DSL/InstallUtils/FOSSUtils#install_puppet_agent_pe_promoted_repo_on-instance_method). Follow the link to get API-level docs on this method for more info.