Added security banner on server logins

Added content to sync to /etc/issue or /etc/issue.net.
Configured SSH server to print banner.
Added unit tests for rjil::system.
Merge pull request #61 from hkumarmk/added_banner

Added security banner on server logins
Install modules in /usr/share rather than /etc
Merge pull request #65 from sorenh/master

Install modules in /usr/share rather than /etc
Use fgrehm/trusty64-lxc when using the LXC provider
Merge pull request #66 from sorenh/lxc

Use fgrehm/trusty64-lxc when using the LXC provider
Use environment file to populate Vagrant config
Don't try to install Puppet every single time.
Don't hardcode IP for proxy. Rely on environment.
Ensure etcd discovery token is set

Bail out if it's not already set in the VM and not available in the
environment. If it'se available in the environment inject it into the
VM.

Provide newtokens.sh to fetch new tokens.
Run puppet more like userdata

...and make maybe-upgrade.sh work, too.
Added haproxy for contrail

1. Added rjil::haproxy::contrail to load balance contrail api services
2. Changed rjil::haproxy_service to support different listen and balancer ports
3. Added spec tests.

Changed lb-stats port of haproxy to 8094 as the port 8084 is used by contrail.
Sync lib and site.pp
Stop running tests from Vagrantfile
Merge pull request #69 from sorenh/vagrantfile

A bunch of Vagrantfile improvements
Make environment confiugurable in vagrant

allow users to set env as an env var to change
what cloud file and env are used for deployment.
Merge pull request #72 from bodepd/vagrantfile_fixes

Vagrantfile fixes
Adjust controller node definitions

This patch updates the controller definitions to
add modify the existing controller definition and
add 2 additional controller types.

* ocdb - this is a controller that also has a db installed. Since
  we are not going to be clustering the dbs via galera, it seems
  logical that some controller are going to have dbs and some are not.
  Additonal (since my intention is to install 1 ocdb and scale out ocs),
  I have also moved the keystone object creation code to this role. This
  code should live on the 'master' controller to ensure that multiple
  machines do not try to manaage it at once.

* oclb - this is a role that contains an openstack controller as well
  as a load balancer. Until we have performance data that indicates that
  we should not be deploying haproxy together with controllers, we should
  plan on deploying them together.
Add service discovery to haproxy and glance

Both of these services need to be discoverable b/c
other roles have to configure themselves to use these
roles.

The load balancer may be a bit tricker (assuming that
we attach a floating ip address), so this is possibly
a temporary solution.
Move towards an eventually consistent cross host deployment model

The original design was based on the idea that all cross host
dependencies could be made in such a way such that they always
flowed in a single direction (ie: no circular dependencies).

After more considerations, this model is not going to support
some of our deployment requirements for openstack.

This patch makes 2 additional that convert the deployment process
from something strictly consistent to something eventually consistent.

1. make custom hiera backend way more forgiving

Previously, the backend would raise an exception and halt Puppet as
a catalog compilation failure. This meant that each host had to be
able to configure itself in one single run. Now, failure to look
up array data just means that it reverts to whatever defaults it
may need. This means that Puppet can perform partial runs, ensuring
that the service discovery file gets written even when the required
data is not ready.

2. publish services to etcd immeditately after run

so that even a run missing data (or one doomed to fail b/c of missing
requirements) can still publish its service for other services to
avoid deadlock.

NOTE: this solution will work, but it is not quite perfect. My main
concern with this approach is that it requires puppet runs to fail
multiple times before eventually resulting in a successful run. In essence,
the runs are eventually consistent (meaning that they will fail on each
node until enough data is ready for the cluster to activate). My concern
with this model is that not all failure states are going to be recoverable,
and it will be really hard to understand expected vs. unexpected failure
states. This is the exact reason that we are looking at moving all cross
host coordination to etcd. My other concern is that the results are
possibly non-deterministic. Depending on the order in which things happen
across multiple hosts, the same code could result in either a functional
or a non-functional cluster. ALthough I don't have evidence that this is
true, I also don't feel that it can be guarenteed these things won't
happen.