Update log message for scale out/in

When create two stacks with same template with autoscaling group,
then when scale out/in, the log message would be as
(HadoopSlaveScaleUpPolicy is my scale up alarm and HadoopSGroup is
my autoscaling group):

HadoopSlaveScaleUpPolicy Alarm, adjusting Group HadoopSGroup by 1

From above log message, I do not know which stack is being scaled up.

This patch add scale group id to the log message so that we can know
which group is being scale out/in.

Change-Id: Ie4862e9738c652b813b3dae01f9aeb3557e79b9a
Closes-Bug: #1265315
Improve tools/uninstall-heat

Inform users that the script doesn't remove related role/user from keystone.

Change-Id: Ia0a7cb37ae568e37c86ff9047361c42186c21ab4
Add documentation for multi-engine

Describe how to set up Heat for a multi-engine deployment in the
document on scaling Heat.

blueprint multi-engine-docs
Change-Id: I5db28b3bc8f5f5dda2d86d052223159adef5f5f0
Introduce a way to trace a resource's implementation

We need a way to know whether a resource is really the
same during update. This is driven by TemplateResource
but not totally specific to it.

The problem is:
if you update a template with no changes (except for environment
or files changes) we need to know which resources to update.

This patch adds a "implementation_signature()" method that gives
us a mechanism to keep track of implementation changes like:
- a change in an environment mapping a resource to a new/different implementation
- a change in the content of a TemplateResource

And can distinguish between schema changes (requiring replacement) and
incremental changes (that can be updated in place).

Change-Id: I780074a827e3f51dede47a81f15e29dbe4d08804
Closes-bug: #1254966
Validate number of instance metadata entries

The Server resource arbitrarily limits instance metadata to five
entries, when the actual provider's maxServerMeta limit could be much
higher.  Make the Server resource check the provider's maxServerMeta
absolute limit and enforce that limit in validate().

Change-Id: Ic00fc6f3a41ae783e43bd7f2df8663263d9cbf90
Closes-Bug: #1260427
Fix schema format in template generation unit tests

Change-Id: I0c13d972100596e33e3f439e97326144a7fabbb4
remove obsolete comment from rackspace clients.py

Removing outdated comment from clients.py.

Change-Id: I06a86555996112130fdb7847de5d20042670c818
Remove override of "patch" function

Overriding the patch method with an incompatable argument
list breaks contrib tests that used the version from
TestCase. This method was introduced in commit
3eda05a9b0b69803a0269f2aa344d14e5823bf6d but removing this
method does not affect other tests.

Change-Id: Iaecd171e5a548b2843b46e7c4b8ef48c52af6db6
Closes-Bug: 1263241
Add ability to configure Heat and Trove client options

Make the client parameters "ca_file", "cert_file" "insecure" and
"key_file" configurable for Heat client and Trove client.
Partial-Bug: #1263165

Change-Id: If5e1669327db91fa2e0482b429611757df21fa88
Enable parallel while deleting neutron resources

The confirm delete task was run immediately after creation in
handle_delete, which blocked the whole DependencyTaskGroup.
This patch gives other delete jobs a chance to run by stepping
the delete task in check_delete_complete.

Change-Id: I9ced21d3f98d949bd099bead27ac7b3e2d1090de
Avoid error on double-delete of nested stack

When deleting a stack that has a nested stack previously deleted, the
process fails because the nested stack cannot be retrieved from the
database.
To solve the bug, the nested stack is now retrieved from the database
ignoring the deleted stacks before the deletion process begins. Then
a NotFound exception is raised, and then when it's catched the nested
stack will be ignored.

Change-Id: Ib863527dbfb0200b833a4e90b5a4fd50f469c1ce
Closes-Bug: #1261436
Fix more regressions in contrib

Changes to contrib resources to use the new properties Schema caused
regressions in the Cloud LoadBalancer resource.

Change-Id: I46a19ef4b0248a6c60f11f963350975c6b86349c
Service authorize stack user from provided stack

Currently _authorize_stack_user requires that an EC2
keypair comes from an AccessKey resource (or some other resource
which uses the access_key as its resource_id).

This change avoids the separate db resource lookup, and checks
the provided stack for a resource which has an associated access_key.

This could be an AccessKey resource, or any resource which has
registered an access allowed handler via register_access_allowed_handler.

Additionally, the credential_id does not have to be the AccessKey of a
keypair. credential_id could be any value meaningful to the resource
which registers the handler.

Since resources are lazy loaded, register_access_allowed_handler will not
be called until resources are loaded. This loading is triggered in
access_allowed by accessing the resources property.

One of the objectives of hot-software-config is to reduce the
amount of template scaffolding required to enable software configuration.
This change means that an OS::Nova::Server resource wouldn't need
an associated OS::Heat::AccessPolicy, AWS::IAM::User, AWS::IAM::AccessKey
just so that os-collect-config can poll for metadata changes (note that
the actual change that does this for OS::Nova::Server is pending).

partial blueprint: hot-software-config
Change-Id: I52a12ad3cd750ed724893abcd6dc1084b925c089
Tolerate deleted trust on stack delete

Currently if a trust has already been deleted, the stack delete
fails and the stack becomes undeletable, so instead catch the
NotFound exception on trust delete, as there's nothing to do.

Change-Id: I1346cefdf6c5f2dea2bc9e2fdd4b9e7b14d60c31
Closes-Bug: #1266434
Update Loadbalancer default template to F20 image

Update the hard-coded default template for the LoadBalancer
resource, so it uses an image called F20-x86_64-cfntools

The Fedora cloud images now contain heat-cfntools, and I've
tested with Fedora-x86_64-20-20131211.1-sda.qcow2, downloaded
from http://fedoraproject.org/en/get-fedora#clouds and it works.

You can download this image direct to glance by doing:

glance image-create --name F20-x86_64-cfntools --disk-format qcow2 \
     --container-format bare --is-public true --copy-from \
     http://cloud.fedoraproject.org/fedora-20.x86_64.qcow2

For users of other distros, you can now override the default
template by copying the built-in template and specifying whatever
image or LB configuration you wish, see
https://review.openstack.org/#/c/64874/

Change-Id: I95e0451b03118a75be0a25f512304649eae42356
Closes-Bug: #1234375
Store AccessKey secret_key in resource data

Similar to the change for SignalResponder, store the secret key
encrypted in resource data, rather than requesting it from keystone
every time the user requests the SecretKey attribute.

Unlike SignalResponder (which stores the signed URL after using
the keypair to sign the request), we need this to be backwards
compatible, to cope with upgrading heat with stacks in the DB
which contain the AccessKey resource but don't have the secret
stored.

blueprint: instance-users
Related-Bug: #1262177

Change-Id: I92826a6dc028b151d98c0a5e2f6ec27db4b744b9
heat_keystoneclient revise get_ec2_keypair

Modify get_ec2_keypair so it's no longer making assumptions about the
number of keypairs a user has, instead we provide create_ec2_keypair,
which just creates and returns a keypair, and get_ec2_keypair just gets
a specified keypair by user and access key ID.

It's now up to the calling resources to manage the lifecycle of the keypairs
(which they should be doing anyway..).  Also make the user_id optional.

Change-Id: I28aa0c2d764b9e957302269598a5910346363d0f
Related-Bug: #1089261
blueprint: instance-users
Fix unused variables 1/2: add more asserts

Add test asserts for some unused local variables to make test better.

Change-Id: I8c830b4680a2ffe8bf1b7cbd44cd1dce5b27c919
Fix unused variables 2/2: enable unused var check

To make code simple and clean and enable unused local variables(F841)
check.

Change-Id: I420e4b3c8845efc616d447922122167af383dbc1
Merge "Avoid error on double-delete of nested stack"