Check that personality is provided before iterating

Change-Id: I3453dee8ce3ec1fd7fba9de16c82f9a6788a7be2
Closes-Bug: #1324619
Remove optional imports from clients.py

Why:
- These are in the requirements
- Heat is now well down the path of been a part of the integrated release
- All of the above clients are also integrated.
- If someone wants to use heat on an old OpenStack they still can
  as long as they install the required recent client libraries,
  which are backwards compatible with older OpenStack releases.

Change-Id: I39d7dcbd3e5655d3da1c97de5ff7eceb1826d4ea
Fixes-bug: #1174005
Implement caching of resource attributes

The default caching mode cache_local will return the previously
resolved value if it is available.

Whenever any resource changes state, all resource attribute caches
are cleared just in case the state change has side-effects in
other resources.

The caching mode cache_none performs no caching, and is chosen
for attributes which are one of the following:
* Derived from any resource's metadata, resource data or resource_id
* An API call which returns a secret

Caching currently only exists for the duration of the parser.Stack
object, but there is future potential for a caching mode which
caches attributes spanning multiple requests.

Closes-Bug: #1321970

Change-Id: I01bf2983b726f0e81a2b8d5be94627353bdeb406
Move Engine initialization into service start()

Currently we create the ThreadGroupManager and EngineListener
objects in the service constructor, which is not necessarily
going to work if multiple worker processes are specified in
the config file (which fork multiple workers after the constructor).

The ThreadGroupManager appears to work, even when it is created before
the fork, but this is due to some magic in the oslo ProcessLauncher
implementation which decouples parent/child use of the eventlet hub.

So instead, we move all service startup code into the start() method,
which is the entry point for services, triggered via the oslo Services
class run_service method:

- Don't create anything common to the workers in the constructor
- Move ThreadGroup and EngineListener creation into start()
- Create the periodic tasks from bin/heat-engine, which means
  the periodic tasks will only be created by the parent, not
  duplicated in every worker process.

These changes should mean we work correctly with both the ServiceLauncher
(num_engine_workers==1) and ProcessLauncher(num_engine_workers>1) oslo
abstractions, and solves the issues observed when running multiple
workers with the impl_qpid rpc_backend.

Change-Id: If3a11050a03660560a364dec871f85c4b56c1c25
Closes-Bug: #1321303
Set rollback status early in update if triggered

Before when rollback was triggered during stack update, the stack continued to
have status UPDATE_IN_PROGRESS, and only at the very end flipped to
ROLLBACK_COMPLETE.
This patch sets the stack state to ROLLBACK as soon as
rollback is started to notify the user properly on the action being
performed.

Change-Id: Idbd78a3a2a8d0c32fb26c7d0c38c87857d1565d8
Closes-Bug: #1316558
Support of regional endpoinds using Keystone v2

Handles the configuration region_name_for_services
with the keystone V2 authentication.

Change-Id: Ibba4d617937da8ba6018471e9614259e90409a47
Heat and Openstack incomplete documentation

Improve documentation running a heat template with devstack

Change-Id: Ifb6abd30a882d4c5197090c87498781702488b9c
Closes-Bug: #1326089
Fix spelling in a doc string

Change-Id: I7f09cfd7892fce64c99484a36b22ec6a6bada6b1
Don't log entire template

In the engine, we log the entire template at info level
It's probably better, and more secure, to just log a message
saying the create/update is happening.

Change-Id: I6490656e0b6737c34f6a5abb36aa736946a7a44c
ec2token tolerate fully-qualified ec2authtoken auth_uri

If (as is currently done by the puppet-heat manifiests) the ec2authtoken
auth_uri is specified, and it looks like http://127.0.0.1:5000/v2.0/ec2tokens
ec2token authentication will fail, because we always append "ec2tokens" to
the auth_uri.  Instead, only add it when needed.

This probably needs to be combined with a change to the puppet manifiests so
we don't set the ec2authtoken auth_uri, as it's an optional section - we can
derive the correct path with only the auth_uri from the keystone_authtoken
section.

Change-Id: I8c89772b40523b30f1c46b2ca8b68f9e20d5c213
Closes-Bug: #1318599
Ensure routing key is specified in the address for a direct producer

This change is already merged in oslo-incubator.  Original commit
message body includes:

    Porting this fix from oslo.messaging.  This fixes the impl_qpid.py
    driver to allow it to work with the latest stable upstream QPID broker
    (version 0.28).  See the Apache Qpid Jira bug
    https://issues.apache.org/jira/browse/QPID-5557

Change-Id: If71f78e50f8a9b3acfd1e9d02c8271f17c4ebee7
Related-Bug: #1300318
Add OS::Glance::Image resource

Add OS::Glance::Image resource.
Implements: blueprint glance-image

Change-Id: If0b5f322da758973d6b47f9ca6888fef40f92f45
Fix property-parameter mapping for boolean property

resource-template returns wrong parameter type "string" for
boolean property, which is wrong after boolean-parameter-type
(commit:6984a7793883164af0e28c3e707048e989670e9d) was merged.
boolean property should be mapped to parameters.Schema.BOOLEAN

Change-Id: I9841545a8e740ecf5ba1806e807bbe15feede69f
Closes-Bug: #1328022
Use auth_token_info to initialize heat_keystoneclient sessions

Now we have the token info available in the request context, we can
avoid always re-requesting another token every time a client is
created.

This should be better for performance as it avoids one extra request to
keystone, and it also enables trust-scoped tokens to be more easily
used, since these cannot be used to request another token, thus
authentication will fail with the current scheme.

Partial-Bug: #1317293
Change-Id: I18955d79c4c760ff3fdd47176a2a54c931277121
Deprecate old schema definition in dbinstance

using new schema definition for dbinstance in test_dbinstance.py,
the old definition is deprecated.

Change-Id: I648074ff9c7d84af5dc5b3765642244fcf7a870f
Respect schema data type in constraint validation

This patch makes Constraint objects aware of the data type of the
owning Schema object so constraint validation can apply potential
type casts based on the data type.
This is especially useful and necessary for an AllowedValues
constraint and numeric values, where items may be defined as
strings or numbers and cause comparison issues with user values
at runtime.

Change-Id: Id1884b4968993fc9356e7ba4ad03dced4cd00d4e
Closes-Bug: #1321540
Merge "Don't log entire template"
Merge "Implement caching of resource attributes"
Merge "Add OS::Glance::Image resource"
Add AllowedValues constraint to Rackspace::Cloud::LoadBalancer

The Rackspace Cloud Load Balancer service only allows certain
values for the algorithm property. This patch adds constraints
so that users get validation feedback prior to creating the
resource.

Closes-Bug: #1328654
Change-Id: Id24b426b1d3e49b09b3e468ea9e9675c05eaa160