beaker 3.20.0 → 3.21.0

data/docs/how_to/hypervisors/ec2.md

@@ -1,81 +0,0 @@
-Pre-requisite: .fog file correctly configured with your credentials.
-
-hypervisor: ec2
-
-### example .fog file ###
-    :default:
-      :aws_access_key_id: IMTHEKEYID
-      :aws_secret_access_key: IMALONGACCESSKYE
-
-### Basic ec2 hosts file ###
-    HOSTS:
-      centos-5-64-1:
-        roles:
-          - master
-          - dashboard
-          - database
-          - agent
-        vmname: centos-5-x86-64-west
-        platform: el-5-x86_64
-        hypervisor: ec2
-        amisize: c1.medium
-        snapshot: pe
-        user: ec2-user
-      centos-5-64-1:
-        roles:
-          - agent
-        vmname: centos-5-x86-64-west
-        platform: el-5-x86_64
-        hypervisor: ec2
-        amisize: c1.medium
-        snapshot: pe
-        user: ec2-user
-    CONFIG:
-      nfs_server: none
-      consoleport: 443
-
-Currently, there is limited support EC2 nodes; we are adding support for new platforms shortly.
-
-AMIs are built for PE based installs on:
-  - Enterprise Linux 6, 64 and 32 bit
-  - Enterprise Linux 5, 32 bit
-  - Ubuntu 10.04, 32 bit
-
-Beaker will automagically provision EC2 nodes, provided the 'platform:' section of your config file lists a supported platform type: ubuntu-10.04-i386, el-6-x86_64, el-6-i386, el-5-i386.
-
-### Supported EC2 Variables ###
-These variables can either be set per-host or globally.
-####`additional_ports`####
-Ports to be opened on the instance, in addition to those opened by Beaker to support Puppet functionality.  Can be a single value or an array.  Example valid values: 1001, [1001], [1001, 1002].
-
-Ports opened by default:
-* all hosts have [22, 61613, 8139] opened
-* `master` will also have 8140 opened
-* `dashboard` will also have [443, 4433, 4435] opened
-* `database` will also have [5432, 8080, 8081] opened
-
-####`amisize` ####
-The [instance type](https://aws.amazon.com/ec2/instance-types/) - defaults to `m1.small`.  
-####`snapshot`####
-The snapshot to use for ec2 instance creation.
-####`subnet_id`####
-If defined the instance will be created in this EC2 subnet.  `vpc_id` must be defined.  Cannot be defined at the same time as `subnet_ids`.
-####`subnet_ids`####
-If defined the instace will be crated in one of the provided array of EC2 subnets.  `vpc_id` must be defined.  Cannot be defined at the same time as `subnet_id`.
-####`vmname`####
-Used to look up the pre-defined AMI information in `config/image_templates/ec2.yaml`.  Will default to `platform` if not defined.
-#####Example ec2.yaml#####
-In this example the `vmname` would be `puppetlabs-centos-5-x86-64-west`.  Looking up the `vmname` in the `ec2.yaml` file provides an AMI ID by type (`pe` or `foss`) and the region.
-```
-AMI:
-  puppetlabs-centos-5-x86-64-west:
-    :image:
-      :pe: ami-pl-12345
-    :region: us-west-2
-```
-####`volume_size`####
-Size of the [EBS Volume](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSVolumes.html) that will be attached to the EC2 instance.
-####`vpc_id`####
-ID of the [VPC](https://aws.amazon.com/vpc/) to create the instances in.  If not provided will either use the default VPC for the provided region (marked as `isDefault`), otherwise falls back to `nil`.  If subnet information is provided (`subnet_id`/`subnet_ids`) this must be defined.
-####`user`####
-By default root login is not allowed with Amazon Linux. Setting it to ec2-user will trigger `sshd_config` and `authorized_keys` changes by beaker.

data/docs/how_to/hypervisors/google_compute_engine.md

@@ -1,41 +0,0 @@
-This option provisions instances from pre-existing Google Compute Engine images.  Currently only supports debian-7 and centos-6 platforms (<a href = "https://developers.google.com/compute/docs/images#availableimages">Google Compute Engine available images</a>)
-
-Pre-requisites:
-
-  * A Google Compute Engine project.
-  * An active service account to your Google Compute Engine project (<a href = "https://developers.google.com/drive/service-accounts">Service Accounts Documentation</a>), along with the following information:
-    * The service account private key file (named xxx-privatekey.p12).
-    * The service account email address (named xxx@developer.gserviceaccount.com).
-    * The service account password.
-  * A passwordless ssh keypair (<a href = "http://www.linuxproblem.org/art_9.html">SSH login without password</a>, <a href = "https://developers.google.com/compute/docs/console#sshkeys">Setting up Google Compute sshKeys metadata</a>).
-    * Name the pair `google-compute`
-    * Place the public key in your Google Compute Engine project metadata
-      * `key`: `sshKeys`
-      * `value` is the contents of your google_compute.pub with "google_compute:" prepended, eg:
-<pre>
-google_compute:ssh-rsaAAAABCCCCCCCCCCDDDDDeeeeeeeeFFFFFFFGGGGGGGGGGGGGGGGHHHHHHHHiiiiiiiiiiiJJJJJJJJKKKKKKKKKlllllllllllllllllllMNOppppppppppppppppppQRSTUV123456789101010101101010101011010101010110/ABCDEFGHIJKLMNOP+AB user@machine.local </pre>
-
-### example GCE hosts file###
-
-    HOSTS:
-      debian-7-master:
-        roles:
-          - master
-          - agent
-          - database
-        platform: debian-7-wheezy-xxx
-        hypervisor: google
-      centos-6-agent:
-        roles:
-          - agent
-        platform: centos-6-xxx
-        hypervisor: google
-    CONFIG:
-      nfs_server: none
-      consoleport: 443
-      gce_project: google-compute-project-name
-      gce_keyfile: /path/to/*****-privatekey.p12
-      gce_password: notasecret
-      gce_email: *********@developer.gserviceaccount.com
-
-Google Compute cloud instances and disks are deleted after test runs, but it is up to the owner of the Google Compute Engine project to ensure that any zombie instances/disks are properly removed should Beaker fail during cleanup.

data/docs/how_to/hypervisors/vagrant.md

@@ -1,165 +0,0 @@
-# Vagrant
-
-Vagrant's slogan is "development environments made easy". They provide an
-abstraction on top of a VM or cloud provider that allows you to manage
-hosts and their provisioning. [Their Site](https://www.vagrantup.com/).
-
-# Getting Started
-
-### Requirements
-
-A prerequisite for using the vagrant hypervisor with beaker is that the
-**Vagrant 1.7+** package needs to installed - 
-see [downloads.vagrantup.com](http://downloads.vagrantup.com/) for downloads.
-
-Currently, we provide a suite of pre-built, publicly available vagrant boxes for
-use in constructing tests: [Puppet Labs Vagrant Boxes](https://vagrantcloud.com/puppetlabs/).
-You can use these boxes easily by pulling one of our
-[Example Vagrant Hosts Files](vagrant_hosts_file_examples.md).
-
-### Setup a Vagrant Hosts File
-
-A vm is identified by `box` or `box_url` in the config file.  No snapshot name
-is required as the vm is reverted back to original state post testing using
-`vagrant destroy --force`.
-
-**Example Vagrant hosts file**
-
-    HOSTS:
-      ubuntu-1404-x64:
-        roles:
-          - master
-          - agent
-          - dashboard
-          - cloudpro
-        platform: ubuntu-1404-x86_64
-        hypervisor: vagrant
-        box: puppetlabs/ubuntu-14.04-64-nocm
-        box_url: https://vagrantcloud.com/puppetlabs/boxes/ubuntu-14.04-64-nocm
-    CONFIG:
-      nfs_server: none
-      consoleport: 443
-
-VagrantFiles are created per host configuration file.  They can be found in the
-`.vagrant/beaker_vagrant_files` directory of the current working directory in a
-subdirectory named after the host configuration file.
-
-    > beaker --hosts sample.cfg
-    > cd .vagrant/beaker_vagrant_files; ls
-    sample.cfg
-    > cd sample.c
-
-Below are details of vagrants features as they're supported through beaker. If
-you'd like to see more examples of vagrant hosts files, checkout our
-[vagrant hosts file examples doc](vagrant_hosts_file_examples.md).
-
-# Vagrant-Specific Hosts File Settings
-
-### Running With a GUI
-
-It is possible to have the VirtualBox VM run with a GUI (i.e. non-headless mode)
-by specifying ``vb_gui`` of any non-nil value in the config file, i.e.:
-
-**Example Vagrant hosts file with vb_gui**
-
-    HOSTS:
-      ubuntu-1404-x64:
-        roles:
-          - master
-          - agent
-          - dashboard
-          - cloudpro
-        platform: ubuntu-1404-x86_64
-        hypervisor: vagrant
-        box: puppetlabs/ubuntu-14.04-64-nocm
-        box_url: https://vagrantcloud.com/puppetlabs/boxes/ubuntu-14.04-64-nocm
-        vb_gui: true
-    CONFIG:
-      nfs_server: none
-      consoleport: 443
-
-### Mounting Local Folders
-
-When using the Vagrant Hypervisor, beaker can mount specific local directories
-as synced_folders inside the vagrant box. This is done by using the
-`mount_folders` option in the nodeset file.
-
-**Example hosts file**
-
-    HOSTS:
-      ubuntu-1404-x64-master:
-        roles:
-          - master
-          - agent
-          - dashboard
-          - database
-        platform: ubuntu-1404-x86_64
-        hypervisor: vagrant
-        box: puppetlabs/ubuntu-14.04-64-nocm
-        box_url: https://vagrantcloud.com/puppetlabs/boxes/ubuntu-14.04-64-nocm
-        mount_folders:
-          folder1:
-            from: ./
-            to: /vagrant/folder1
-          tmp:
-            from: /tmp
-            to: /vagrant/tmp
-        ip: 192.168.20.20
-      ubuntu-1404-x64-agent:
-        roles:
-          - agent
-        platform: ubuntu-1404-x86_64
-        hypervisor: vagrant
-        box: puppetlabs/ubuntu-14.04-64-nocm
-        box_url: https://vagrantcloud.com/puppetlabs/boxes/ubuntu-14.04-64-nocm
-        ip: 192.168.21.21
-    CONFIG:
-      nfs_server: none
-      consoleport: 443
-
-In the above beaker will mount the folders `./` to `/vagrant/folder1` and the
-folder `/tmp` to `/vagrant/tmp`.
-
-### Forwarding Ports to Guest
-
-When using the Vagrant Hypervisor, beaker can create the Vagrantfile to forward specified ports to a specific box. This is done by using the `forwarded_ports` option in the nodeset file.
-
-**Example hosts file**
-
-    HOSTS:
-      ubuntu-1404-x64-master:
-        roles:
-          - master
-          - agent
-          - dashboard
-          - database
-        platform: ubuntu-1404-x86_64
-        hypervisor: vagrant
-        box: puppetlabs/ubuntu-14.04-64-nocm
-        box_url: https://vagrantcloud.com/puppetlabs/boxes/ubuntu-14.04-64-nocm
-        ip: 192.168.20.20
-      ubuntu-1404-x64-agent:
-        roles:
-          - agent
-        platform: ubuntu-1404-x86_64
-        hypervisor: vagrant
-        box: puppetlabs/ubuntu-14.04-64-nocm
-        box_url: https://vagrantcloud.com/puppetlabs/boxes/ubuntu-14.04-64-nocm
-        ip: 192.168.21.21
-        forwarded_ports:
-          apache:
-            from: 10080
-            to: 80
-          tomcat:
-            from: 8080
-            to: 8080
-            from_ip: '127.0.0.1'
-            to_ip: '0.0.0.0'
-
-In the above, beaker will forward port 10080 and 8080 on the Host to port 80 and 8080 (respectively) on the Agent guest.
-
-# vagrant plugins #
-
-You can check more information for some suported vagrant plugins:
-
- - [vagrant-libvirt](vagrant_libvirt.md)

data/docs/how_to/hypervisors/vagrant_hosts_file_examples.md

@@ -1,60 +0,0 @@
-#centos-511-x64.yml
-```
-HOSTS:
-  centos-511-x64:
-    roles:
-      - master
-    platform: el-5-x86_64
-    box: puppetlabs/centos-5.11-64-nocm
-    hypervisor: vagrant
-```
-#centos-65-x64.yml
-```
-HOSTS:
-  centos-65-x64:
-    roles:
-      - master
-    platform: el-6-x86_64
-    box: puppetlabs/centos-6.5-64-nocm
-    hypervisor: vagrant
-```
-#debian-609-x64.yml
-```
-HOSTS:
-  debian-609-x64:
-    roles:
-      - master
-    platform: debian-6-amd64
-    box: puppetlabs/debian-6.0.9-64-nocm
-    hypervisor: vagrant
-```
-#debian-78-x64.yml
-```
-HOSTS:
-  debian-78-x64:
-    roles:
-      - master
-    platform: debian-7-amd64
-    box: puppetlabs/debian-7.8-64-nocm
-    hypervisor: vagrant
-```
-#ubuntu-server-1204-x64.yml
-```
-HOSTS:
-  ubuntu-server-1204-x64:
-    roles:
-      - master
-    platform: ubuntu-1204-amd64
-    box: puppetlabs/ubuntu-12.04-64-nocm
-    hypervisor: vagrant
-```
-#ubuntu-server-1404-x64.yml
-```
-HOSTS:
-  ubuntu-server-1404-x64:
-    roles:
-      - master
-    platform: ubuntu-14.04-amd64
-    box: puppetlabs/ubuntu-14.04-64-nocm
-    hypervisor: vagrant
-```

data/docs/how_to/hypervisors/vagrant_libvirt.md

@@ -1,58 +0,0 @@
-# Vagrant Libvirt #
-
-This driver enabled a tester to trigger tests using libvirtd daemon.
-It is based
-on [libvirt](https://github.com/vagrant-libvirt/vagrant-libvirt)'s
-plugin for vagrant.
-
-## Basic Options ##
-
-Once you've setup the libvirt daemon on your beaker coordinator, you
-can use the vagrant_libvirt hypervisor by providing beaker with a
-configuration similar to this:
-
-```yaml
-HOSTS
-  centos-puppet-keystone:
-    hostname: puppet-keystone.example.net
-    roles:
-      - master
-    platform: el-7-x86_64
-    box: centos/7
-    box_url:  http://cloud.centos.org/centos/7/vagrant/x86_64/images/CentOS-7.LibVirt.box
-    hypervisor: vagrant_libvirt
-    vagrant_memsize: 4096
-    vagrant_cpus: 2
-```
-
-Those are the usual beaker parameters. Note the `hypervisor`
-parameter. Multiple VMs is supported.
-
-
-## Advanced Options and remote libvirt daemon ##
-
-This driver gives the tester access to all available parameters from
-the vagrant-libvirt plugin. Beware there could be dragons here as
-beaker has some expectations about the created VMs.
-
-To pass them down the operator adds them in the config section, here
-is a example.
-
-```yaml
-CONFIG:
-  libvirt:
-    uri: qemu+ssh://root@libvirt.system.com/system
-```
-
-The `uri` parameter is one of the most useful. The user can have its
-test done on a remote libvirt daemon. The network setup between the
-VMs and the host running beaker will have to be done manually though.
-`management_network_name` and `management_network_address` parameters
-can be useful here.
-
-Another good cadidate is `volume_cache: unsafe`.
-
-A complete list of options is available in
-the
-[vagrant plugin](https://github.com/vagrant-libvirt/vagrant-libvirt)
-repository.

data/docs/how_to/hypervisors/vmware_fusion.md

@@ -1,36 +0,0 @@
-Pre-requisite: Fission gem installed and configured, including a `~/.fissionrc`
-that points to the `vmrun` executable and where virtual machines can be found.
-  Example `.fissionrc` file (it's YAML):
-
-    vm_dir: "/Directory/containing/my/.vmwarevm/files/"
-    vmrun_bin: "/Applications/VMware Fusion.app/Contents/Library/vmrun"
-
-You can then use the following arguments in the node configuration:
-- `hypervisor: fusion` tells us to enable this feature for this host. This is required.
-- `snapshot: <name>`, where <name> is the snapshot name to revert to.  This is required.
-
-We'll try and match up the hostname with a VM of the same name. Note that the VM is expected to be pre-configured for running acceptance tests; it should have all the right prerequisite libraries, password-less SSH access for root, etc.
-
-There are a few additional options available in your configuration file. Each host
-section can now use:
-
-- `vmname`: This is useful if the hostname of the VM doesn't match the name of
-  the `.vmwarevm` file on disk. The alias should be something fission can load.
-
-
-### Basic VMWare fusion hosts file ###
-
-    HOSTS:
-      pe-debian6:
-        roles:
-          - master
-          - agent
-        platform: debian-6-i386
-        vmname: super-awesome-vm-name
-        hypervisor: fusion
-        snapshot: acceptance-testing-5
-
-### Diagnostics ###
-
-When using `hypervisor fusion`, we'll log all the available VM names and for each
-host we'll log all the available snapshot names.

data/docs/how_to/hypervisors/vsphere.md

@@ -1,54 +0,0 @@
-This doc describes beaker's vSphere hypervisor. This is the interaction layer
-that beaker will use to get Systems Under Test (SUTs) from any vSphere
-infrastructure that you might have.
-
-**Note** that if you're a puppet-internal user, or an external user that is
-using the vmpooler hypervisor, please refer to our [vmpooler doc](https://github.com/puppetlabs/beaker-vmpooler)
-for info, as it can be different than the information here. 
-
-The harness can use vms and snapshots that live within vSphere as well.
-To do this create a `~/.fog` file with your vSphere credentials:
-
-### example .fog file ###
-
-    :default:
-      :vsphere_server: 'vsphere.example.com'
-      :vsphere_username: 'joe'
-      :vsphere_password: 'MyP@$$w0rd'
-
-These follow the conventions used by Cloud Provisioner and Fog.
-
->Note: Your fog credential file location may be specified in the 'CONFIG' section using the 'dot_fog' setting
-
-There are two possible `hypervisor` hypervisor-types to use for vSphere testing, `vsphere` and `vcloud`.
-
-### `hypervisor: vsphere`
-This option locates an existing static VM, optionally reverts it to a pre-existing snapshot, and runs tests on it.
-
-### `hypervisor: vcloud`
-This option clones a new VM from a pre-existing template, runs tests on the newly-provisioned clone, then deletes the clone once testing completes.
-
-The `vcloud` option requires a slightly-modified test configuration file, specifying both the target template as well as three additional parameters in the 'CONFIG' section ('datastore', 'datacenter', and 'folder').  Optionally, a resourcepool may be specified via the 'resourcepool' setting in the 'CONFIG' section.  Template can be expressed in the 'HOSTS' section, or you can set the template to be used via the `BEAKER_vcloud_template` environment variable.
-
-#### example vcloud hosts file ###
-    HOSTS:
-      master-vm:
-        roles:
-          - master
-          - agent
-          - dashboard
-        platform: ubuntu-10.04-amd64
-        template: ubuntu-1004-x86_64
-        hypervisor: vcloud
-      agent-vm:
-        roles:
-          - agent
-        platform: ubuntu-10.04-i386
-        template: ubuntu-1004-i386
-        hypervisor: vcloud
-    CONFIG:
-      consoleport: 443
-      datacenter: testdc
-      datastore: instance0
-      resourcepool: Delivery/Quality Assurance/FOSS/Dynamic
-      folder: delivery/Quality Assurance/FOSS/Dynamic