Add API endpoint to query build information

This creates the '/<tenant_id>/build_info' endpoint and returns the build revision
as defined in the 'heat_revision' configuration option. This provides
both the revision of the engine and the api:

{
  "api": {
    "revision": <api revision>
  },
  "engine": {
    "revision": <engine revision>
  }
}

Implements: blueprint heat-build-info
Change-Id: Ibb2f5afda7c5d7c314e5e062d618405d9f4eb318
Fn::Replace support for type Number

Currently Fn:Replace works just with type String:
{Fn:Replace [{'str': 'new_str'}, 'change str']}

After this fix it will work for type Number:
{Fn:Replace [{'str': 42}, 'change str']}

Change-Id: I709a3350b5676bd9db8bac92e07ad105466bd187
Closes-Bug: #1256326
Derive context is_admin from policy

Use a rule in the policy.json to correctly derive a user's admin-ness
based on their roles, when it is not explicitly specified in the
RequestContext constructor.

Keystone auth_token tests X-Roles based on the user role membership
for the tenant the token is scoped to, so this will allow us to define
per-tenant admins (the admin everywhere issue described in keystone
bug #968696 won't apply here, that is specific to keystone).

Remove the admin_role config option, which doensn't do anything, and
now this should be specified via policy.json.

Change-Id: I1921a2b515ecc8ca5d37205e3cdb6b7b8695b1ac
bluprint: request-scoping-policy
Remove misleading docstrings in ContextMiddleware

Most of this information is completely wrong, so remove it

Change-Id: I00cc4eae20447c402f1451fe9aa7d72877f2c36c
Remove owner_is_tenant from RequestContext

This appears to be a leftover from glance, and we don't support
anything other than tenant-scoped requests.

Change-Id: Ibce0e38ee24f18de24733a35d25c90c03b46dc6e
blueprint: request-scoping-policy
Fix show_deleted errors in RequestContext

get_admin_context takes a read_deleted argument which is ignored,
and we don't include the read_deleted value in to_dict output.
Fixing this means we can respect this flag in the DB API, which
currently we do not.

Change-Id: Id0906983b93cd2526580942390f7992fb2cb5504
blueprint: request-scoping-policy
Migrate away from rackspace_resource

Having Rackspace specific resources subclass a the rackspace_resource
does not replace the clients system wide. Use the cloud_backend to
acomplish this. That way any special configuration done with pyrax
will be used in any client call.
Change-Id: Ia6d548e606a42c608135cb66876419d1b339a06c
Remove unused fake test code

This just confuses everyone.

bug: #1195452
Change-Id: I9d8524a7619663e5f0e5cce619a0587290ff1db7
Add a .coveragerc to exclude tests and oslo

This is to try produce more relevant output.

Change-Id: I08ebfacf19e4975e00ab79229cc18a3b57a1002a
Sync DB2 error code handling from oslo

Including DB2 error code -30081 in conn_err_codes, so that the
connection retry code will not be skipped when DB2 connection
error happens.

SHA1 of Oslo commit - bdabd512943ebb84a1333b2b3ee31a33124af76e to
which the db module code is syncd.

Change-Id: Idec7a6d712f5ed08fc0daad0a64df203c624f194
Closes-Bug: #1244092
Factor Schema out of properties.py for re-use

There is currently some function duplication in Heat for schema
validation. There is properties.Schema and a ParamSchema class which
do mostly the same, but each with their own code.
It would be good to have a common implementation for property and
parameter validation with only property or parameter specific code
implemented in sub-classes.
The current Schema class in properties.py cannot be used in
parameters.py due to cyclic import dependencies that would arise.

This patch factors the Schema class and Constraint classes into their
own file which can then be imported by both properties.py and
parameters.py. For property schema specific code, a class
PropertySchema is introduced as derived from the common Schema class.

The code of the Schema and Constraint classes is unchanged except for
absolutely  refactoring work.

In a subsequent patch, I plan to provide the code to base ParamSchema
on the common Schema class.

Change-Id: I833edd8fad316220f56d6727fe1e3409f8fda6ee
Partial-Bug: #1230229
run_test.sh -V --unit doesn't run using virtualenv

Before this change, when you called the script using the -V option, the tests
were run outside the virtualenv that the script creates.
To fix it, I modified the lines of the script that run the tests to run
inside the virtualenv using the $wrapper variable.

Change-Id: I5c202727e0b5214670d54e14c80a68cc8ebec400
Closes-Bug: #1251730
Provide access to Trove client

python-troveclient is required for implementing Database As A
Service (DBaaS) resource. This patch makes Heat depend on
python-troveclient and also changing clients.py and resource.py
to provide access to troveclient.

Implements: blueprint dbaas-trove-resource

Change-Id: I010d4a11793cc634aa0af5f01b637fff4effbf61
Merge "Fn::Replace support for type Number"
Add heatclient to available clients

The first resource to use this will need to ensure
that this method has test coverage. There appears to be
no convention for writing separate unit tests for these
client methods.

This will currently not work with standalone heat as
the heat endpoint will not be in the keystone catalog, see
related-bug: #1255713

partial blueprint: hot-software-config
Change-Id: I325664dcb0ca4d01be41614496c92e65bea52310
Merge "Remove unused fake test code"
Merge "Provide access to Trove client"
Bump to sqlalchemy-migrate 0.8.2

This allows us to drop some unsightly sqlalchemy-migrate 0.7.3
patching.

The related requirements change is here:

  Icde6248ca102884323d7912bab0f4a716aa294ec

Change-Id: I5f80dfc07f8256716d025002fc1a1f47e58b2142
Merge "Add heatclient to available clients"
Merge "Derive context is_admin from policy"