Merge pull request #1 from michaeltchapman/pr

Put puppet-postgres at 2.5.0 since the interface has since been changed.
Fix dep issue on redhat

I previously made a modification to the puppet packages
in order to resolve from missing package dependencies
for the Ubuntu packages.

These changes created a dependency loop on the puppet package.

This commit refactors the way in which the puppet packages are
installed so that htey should work on both platforms.
Merge pull request #73 from michaeltchapman/master

Put puppet-postgres at 2.5.0 since the interface has since been changed.
Merge pull request #74 from bodepd/puppet_package_redhat_fix

Fix dep issue on redhat
remove commented out PXE boot VMs

B/C they are no longer being used
Port build node to node data

This commit ports the existing build server role
to be something described completely as data.

This fix is intended to make it easier to combine
this role with other roles to form new roles (
specifically the super all in one with os all in one
+ build + cache)

The patch contains the following parts:
* add support for arrays of post config actions
* remove build server roles
* allow data nodes to express if they want to
use puppet agent or apply (b/c the build node
must use apply)
* allow the apply_manifest to accept a certificate
(in case we need to pass it for site.pp runs)
* remove hardcoded RedHat and Ubuntu builds from
Vagrantfile
* Add new role to 2_role node and scenario
* Add new node to all in one scenario
* add it to role_mapper
* remove node entry from site.pp
* add new build_node class group
Added Puppet module repos to the Puppetfile needed for HA
Merge pull request #76 from CiscoSystems/puppetfile_ha_patch

Added Puppet module repos to the Puppetfile needed for HA
Merge pull request #75 from bodepd/data_build_node

Data build node
Merge branch 'pr'

Conflicts:
	data/nodes/2_role.yaml
Merge branch 'pr'

Conflicts:
	data/nodes/2_role.yaml
Merge branch 'master' of github.com:CiscoSystems/openstack-installer
Add fragments to 2_role node definitions.

These are used to compose the script that will be
passed to cloud-init for each node. Note that there
is a primitive signalling system to ensure things
happen in the correct order.

The script that will be generated for a particular host
under a particular scenario can be viewed by using
stack-builder's frag command like so:

sb frag build-server -s 2_role