Added reference to the Nova Flavor documentation.

Updated contrib documentation with reference to the nova flavour README file.
Fixed the reference to the Docker documentation.

Change-Id: I23e352b8ec44424611066c0f64051ad3586b8c91
Fix test for stack delete on same active engine

The test was not starting the EngineListener, thus the engine_id was
None, so the corresponding code execution path was not actually
exercised.

Change-Id: If48ba9d3deb54f8e9ea1ed1987f832ddbaed33fc
Refactor service readiness notification

Build upon cceda95a35f18f5f7b52daaf0662a4cd3768b3ac apply Oslo systemd
module. It was imported in aef33d2d716c064f1f571c334fd36b1ea5928d5c. It
also drops heat.common.systemd and deprecates onready configuration
parameter.

Oslo commit 53e1214c092f09e3851b1a1b55289a93a72b09ec

Change-Id: I80f325c9be9c171c2dc8d5526570bf64f0f87c78
Policy Enforcer, pass entire context dict

The oslo enforcer expects "as much detail as possible" about the
calling user in the creds dict, so include the whole context dict,
which will enable more complex policy rules to be expressed than
with the current code where we pass only a subset of the context
data.

Change-Id: I70bd0fb07bb0b8e9c3c2b94b399197ad207d0fd2
Refactor AWS::EC2::Instance delete handling

Refactor instance to use the nova_utils delete function.

Closes-Bug: #1329453
Change-Id: Ie84fb3c5c9f6381e4eea3a5e99d62266a8abd023
Add native WaitConditionHandle resource

Adds a native OS::HeatWaitConditionHandle resource, which works
in a similar way to the CFN compatible one, but with a few changes
to make it simpler to use:
- The data passed is validated less strictly, so we tolerate missing keys
  for any of the data (we just fill in default values)
- A signal passed with no data is assumed to mean success
- There are two convenience attributes which provide a string representing
  the necessary curl call to send the signal (to the native ReST API)

This allows a similarly simple signalling mechanism to the CFN compatible
Handle resource, but with no dependency on the ec2tokens keystone extension
or heat-api-cfn service.

Some usage examples here:
  - https://review.openstack.org/106424

blueprint: native-waitcondition
Change-Id: Ie9b5aeb13bfab5fba55c1a49d1572e0777864b29
Update test_signal to use stub_keystoneclient

Adds an argument to stub_keystoneclient such that it can be used to
clean up the stubbing in test_signal

Change-Id: I5b29b0b2dd764c735aa0da7ee8d40d867c8b4f2f
Allow plugins to specify signal event reason

Currently, we have logic in the Resource.signal base-class implementation
which works out the reason string based on knowledge of some of the
signal-handling resources.  This is invariably going to be fragile, and it
won't work at all with any out of tree or contrib plugins.

So instead, move towards a model where we accept an optional return value from
handle_signal, and use that as the reason string instead.  Since no resources
yet return a reason, maintain the old logic as a fallback path, until this
gets migrated into the appropriate resources.

Change-Id: I45fdf112e6cd050bb1f4111977f653ba6440df02
Partial-Bug: #1340894
Merge "Refactor AWS::EC2::Instance delete handling"
Replace str() with six.text_type() where exception is used

When switching to oslo.i18n, tests where used str(exc) will failed
with unicodeerror, so before switching to oslo.i18n, need to
replace str with six.text_type where exception is used. And it's
recommanded to use six.text_type instead of str in openstack.

Change-Id: Ie37a6ef74a12b2580ce72afc75c99bcd19d4cf97
Merge "Policy Enforcer, pass entire context dict"
Stop software_deployments from passing empty keys

When software_deployments was given a body missing the "input_values"
field it would pass update info with input_values=None, which would
later fail and cause an internal server error.

This change prevents software_deployments from passing on NoneType
values.

Change-Id: I02e9c08bbd7429d808de1451de12cc02fc879ecb
Closes-Bug: 1319825
Parse RST in plug-in class docs

In order to make the generated documentation for resource plug-ins more
readable, parse the class comments as RST and append to the section.

Change-Id: Icb37344c64c21bcac536e8f2916b102eb9754851
Add "index_var" property to the resource group resource

This property allows a template author to replace values in the
nested resource_ref with the index of the specific instance of
that resource in the group. This allows a user to, for example,
add the index of the resource to server names in order to make
them more easily distinguishable when listed outside of Heat.

Implemements: blueprint override-resource-name-in-resource-group
Change-Id: I4339067e3b8927573acff0ab5968de61a3253d07
Use standard FnGetAtt method for Swift container

Change-Id: I07b260d11f1c41f6e406f99df77cfad1c65a8a4b
Allow Resources to select paths from attributes

Previously when get_attr included a path to select from the attribute, the
selection was done by the get_attr intrinsic function. Starting with the
Juno version of HOT, move control of this to the resource plugin, so that
individual resources (particularly ResourceGroup) can handle it themselves.

Related-Bug: #1341048
Change-Id: Ic3dc94a99a19e28a4f775198ff6e960e2efb8256
Merge "Use standard FnGetAtt method for Swift container"
Exceptions ResourceInError, ResourceUnknownStatus

Resources which go into an unknown or error state currently
raise an Error exception. There are cases where Error is too
generic to make decisions on, so 2 new exceptions have been
created:
* ResourceInError: raised when a resource goes to a status which
  is known to represent an error for that resource
* ResourceUnknownStatus: raised when a resource goes to a status
  which heat is not aware of. If ResourceUnknownStatus is ever raised
  then this is a heat bug, since this is a status which heat is not
  aware of.

Any resource which go into an in-progress state has been updated to
raise ResourceInError and ResourceUnknownStatus where appropriate.

Change-Id: Ied83b030d30b8c26d9f4a1e454c71cd30715b0ba
Retry resource create until success

On resource create, if a ResourceInFailure is raised then
repeated attempts are made to delete and recreate the resource
until success or a different error state is achieved.

Likewise, the prepare-retry deletes will be retried until
ResourceInFailure is not raised.

An exponentially increasing delay with jitter is introduced
between each create attempt, and attempts continue up to the configured
action_retry_limit or stack operation timeout.

Likewise An exponentially increasing delay with jitter is introduced
between each prepre-retry delete attempt, and delete attempts
continue up to the configured action_retry_limit or stack operation
timeout. The delete attempt count is reset to zero whenever a create
attempt has been performed.

Creates that result from an UpdateReplace will also go
through this path, so this is also helps some stack update scenarios.

This change is aimed at being part of an interim solution to making
heat resilient to transient cloud failures. Convergence is the
permanent solution however there may be benefits to the convergence
implementation from this interim effort.

Currently retry is only attempted on ResourceInFailure. Eventually
client plugins can indicate whether a given exception should lead
to a retry attempt (such as connection errors, some 500s).

Partial-Blueprint: retry-failed-api-calls
Change-Id: I07c3301349bcd24096f3cafbb6d82c43bccb93de
Fixed wait skipped after 1st step of task

The first step of a generator type task is executed by the start
method and subsequent steps are executed by run_to_completion.
The TaskRunner skips the wait between the first step and second
step.
Added the sleep between transition from first step to second step.
Updated corresponding unit tests.

Change-Id: Iff30073ea0c060c6e2c89d7d9df8d0d03e816455
Closes-Bug: #1218187