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.
Adjustments to common data for glance

- set auth_uri as glance api host
- set overridable glance/keystone public/internal
  addresses for endpoints.
Add jiocloud_role fact to hierarchy

This patch adds a new fact called jiocloud_role.

This fact just parses the mathing role out of the
hostname.

It adds this role to the hierarchy as role-env
which takes precedence over env. This means that
you can add role specfic data that applies
only to a specific environment.

This hierarchy was added for cases where a service
might need to resolve data from itself as opposed
to from the service discovery data it is happans
to be providing services itself.
Add services to gitignore

This patch adds services.yaml to gitignore
b/c it is generated dynamically from
each deployment.
Add dan specific environment.

for the purposes of localized testing, it's hard to
imagine that in the near term, we will not have
isolated environment for development and combine
tested code into a single environment for automated
jenkins driven deployments.

Here is mine.
Merge pull request #73 from bodepd/vagrant_basic_controller_deployments

Vagrant basic controller deployments