Opening stable/icehouse

Bump version to next stable release on icehouse branch, and set
defaultbranch in .gitreview for convenience.

Change-Id: I9e7a1e111641bc4f4132b714a66e58fedecb6005
Don't pass enable_snat by default in Router

The patch removes the default for enable_snat in the Router resource and
removes the value if not specified, to make it possible for non-admin
users to create routers: a policy rule in neutron forbids non-admin to
pass the enable_snat value.

It doesn't break backward compatibility as enable_snat is the default in
neutron.

Co-Authored-By: ala.rezmerita@cloudwatt.com
Closes-Bug: #1306593
Change-Id: Ib9d31f7e0a246bcaa663aaa74755526f8e31df7e
(cherry picked from commit d7836e922577f8fad4a2fba4658d4f74ed8a2e4a)
Ignore nova limits set to '-1'

In case nova server has quotas turned off, e.g. when it uses
NoopQuotaDriver, nova-api returns '-1' for corresponding resources which
obviously means 'INFINITY'. In this case we should not check resource
template for any limits and should pass resource creation as-is.

Change-Id: Idaf485719e384f3a613031c7ff272d55798e6e77
Closes-Bug: #1310710
Co-Authored-By: Dmitry Borodaenko <dborodaenko@mirantis.com>
Don't dynamically create provider types in the global env

Only support this in user environments.
Note: this is only when you have the following in your template
resources:
  thingy:
    type: http://example.com/foo.template

Doing this will avoid tenant-specific provider template URLs being
shown globally in the resource-type listing.

Co-Authored-By: Angus Salkeld <angus.salkeld@rackspace.com>
Closes-Bug: #1311223
Change-Id: Ifa18108afacbda390b19b46a8f41bc4f018e95d6
(cherry picked from commit a02ff20509171346d2a1d2a9df7c81aada134c52)
Updated from global requirements

Change-Id: Ie49a7c89304ef682a5703195ff95b94ec3a37e92
Allow NotFound to be created without args

It appears that the serialization used to wrap RPC exceptions
requires that the class be instantiated without any arguments.

Since the NotFound exception required a msg_fmt it could not be
deserialized in heat-api, which lead to no mapping in the FaultWrapper
so a 500 was raised instead of a 404.

This change adds a default value for msg_fmt for the NotFound exception.

The classes Error and ResourceFailure likely have this issue too, but it
is not as serious since they will raise a 500 error anyway.

Config/deployment API tests now check that NotFound can be deserialized by
calling to_remote_error, and checks that FaultWrapper converts that to
HTTPNotFound.

Change-Id: Ieb8de26465cb26aa015f15c134f80a06ebcae95c
Closes-Bug: #1301657
Related-Bug: #1304743
Using correct attribute of exception

Currently patch (https://review.openstack.org/#/c/69837/6) was merged in
python-novaclient. New exceptions have not attribute 'code' and now we
should use http_status instead, falling back to the old attribute if
the new attribute does not exist.

Change-Id: I16e54c8e19dd93229fd7bcfe124fd4f2595f4e59
Closes-bug: #1319499
Catch NotFound for keystone delete operations

If heat-engine is terminated mid-delete, a stack could become
undeletable because of NotFound exceptions being raised on keystone
delete stack domain operations.

This change wraps all keystone delete calls and ignores any NotFound
exceptions raised.

Change-Id: I032b04b1391590a6f9493b65bddff331b07722f0
Closes-Bug: #1308812
Truncate status_reason to column length

This avoids a DataError "Data too long for column 'status_reason'"
when status_reason is longer than 255 chars.

This is implemented in the class StateAware which is extended
by Stack, Resource, and SoftwareDeployment.

Change-Id: I520803e54f9045fce2dc3b6a1b5c3be5052080aa
Closes-Bug: #1312815
Fix status reason in events for deployment signals

When a signal is received and processed by a Resource, there could be an
event generated automatically. For such an event, Heat is supposed to
provide some useful message (including status_reason).  But currently,
the resource code can only process ceilometer alarms and watch rules,
for signals sent for a SoftwareDeployment resource, the signal is only
providing an string 'Unknown' as the status change reason.  This is
confusing when a user performs 'heat event-list stack'.

This patch adds an additional check (guess) whether the signal comes
from a SoftwareDeployment.  If that is the case, fill in the status
reason as 'deployment succeeded', or 'deployment failed (n)', where n is
the deploy_status_code that comes with the signal.

Closes-Bug: #1300679
Change-Id: Ic970a5dac923fffdcdd365983df58f4d338de849
Fix failed to delete the NovaFloatingIPAssociation resource

Unable to delete a CREATE_FAILED stack which the NovaFloatingIPAssociation
resource create failed. So we should check if the resource is not created
successful, don't try to delete it.

Change-Id: I0eba68cc2d84b2c683e66c971534afe55d391949
Closes-bug: #1318869
Avoid redundant polling of DB for metadata

Every time self.metadata is read, it triggers a refresh from the database.
We were accessing it multiple times in a loop, which is not only wasteful
but can get very O(n^2) for a WaitCondition with a high Count.

Partial-Bug: #1306743

Change-Id: I1a82afac6c4ef56dbf87722648034c05abef4010
Merge "Ignore nova limits set to '-1'" into stable/icehouse
Merge "Updated from global requirements" into stable/icehouse
Merge "Fix failed to delete the NovaFloatingIPAssociation resource" into stable/icehouse
Merge "Truncate status_reason to column length" into stable/icehouse
Merge "Catch NotFound for keystone delete operations" into stable/icehouse
Merge "Using correct attribute of exception" into stable/icehouse
Merge "Avoid redundant polling of DB for metadata" into stable/icehouse
Merge "Fix status reason in events for deployment signals" into stable/icehouse