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
Validate user_data_format for server with deployment

Validation error will be raised if user_data_format is not set
correctly.

Partial-Bug: #1295536
Change-Id: I0509c9c3a71d09fa8e2113710d561ffd3289d814
Move API parameter parsing from engine to API

API parameter parsing should be done in the API rather than the engine.

Change-Id: I133f419bbb73964b461572d8cadd300233af9c12
Fix validate failed with an image_name in uuid format

We should support to get the image_id by an image_name which is in uuid
format.

Change-Id: I471ee57ea55f990f852398a43762899dbc3d8692
Closes-Bug: #1312523
Refactor boolean conversion into a separate function

A method to convert API parameters to boolean values will be useful for
parsing the show_deleted API parameter, so create a separate function
named extract_bool.

blueprint stack-list-soft-deleted

Change-Id: I1bce5516b0a8c97d6c08607922968454d94b4406
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
Engine changes for API param to show soft-deleted stacks

blueprint stack-list-soft-deleted

Change-Id: Ie649d9a2b4132795e048325dedc46900c6f34eac
API changes for param to show soft-deleted stacks

blueprint stack-list-soft-deleted

Change-Id: I9b56ee877746c25c6acefb91fc3eae63701aedd6
Use the new oslotest library

There is a new support library extracted from oslo incubator: the patch
starts using it and removes deprecated modules.

Change-Id: I3839af20613ff6ab905dddb8fc4be65654c6e949
Add a Nova Flavor resource.

This will allow using more fine-grained specification of computational
resources (RAM, CPU, disk, etc.).

A nova flavor resource has the following format:

  heat_template_version: 2013-05-23
  description:  Heat Flavor creation example
    resources:
      test_flavor:
        type: OS::Nova::Flavor
        properties:
          ram: 1024
          vcpus: 1
          disk: 20
          swap: 2

Change-Id: I79812f0ef0d0dc616ccb3361e9b5864faa877df1
Implements: blueprint dynamic-flavors
Autoscaling: compare fully-resolved templates

The Resource.t snippet is a parsed but unresolved template snippet. In
practice there should be no intrinsic functions included to resolve at the
moment, but in principle we should do comparisons on the fully-resolved
result.

Change-Id: I12d2e7c8282ddfbb7cca4930ef557ce3856a88b5
Unit tests: tidy up resolve_runtime_data() calls

It's not clear whether these were ever needed or just cargo-culting, but
they are definitely not doing anything now.

Change-Id: I9dd409332a93e39640da93a22cf7d3c676f398ac
Pass unresolved template to Resource.update()

Previously the 'after' template passed to Resource.update() was completely
resolved. This led to an odd situation where the contents of a resource's
template snippet were either unresolved (but parsed) or resolved depending
on whether the resource had been updated or not. Resolve (ha!) this
discrepancy by passing a version of the template with the intrinsic
functions unresolved.

Change-Id: I8c11cdc3c28661db689b416833bde34cea12d98a
Deprecate Stack.resolve_runtime_data()

This no longer needs to be done in the context of a stack, because all of
the required context is embedded in the lazily-evaluated functions at the
time they are parsed into Functions. Reduce confusion by eliminating all
uses of it and marking it as deprecated.

Change-Id: I9d89b5201df5b05d03a295eaf6605da65397f565
Clean up openstack-common.conf

oslo-incubator will introduce new integrity check in [1].
That will help developer find inconsistent issue while copying
from oslo-incubator. The check just outputs warnings. These are
changes according to warning:
 * remove unused module py3kcompat
 * add missing module context, processutils in openstack-common.conf
 * sort the modules in openstack-common.conf
[1] https://review.openstack.org/#/c/76901/

Change-Id: I2fea01148f6ad268a5fcfdaa788e30d6fcb48c3f
Related-Bug: #1295582
Do not initialise stack_user password

Since Server implements this property with @property decorators,
setting password to None has the side-effect of writing None to
the resource data.

This change fetches the password with getattr instead.

Change-Id: I1107ee9710ec8520d7231c5b8b711e21b4183a34
Use resource methods for metadata get/set

The current approach of using the Metadata descriptor
class has some issues including:
* Unintended database queries on accessing a metadata attribute
* get/modify/set patterns since the attribute isn't backed by a real dict
* lack of control over whether to fetch metadata locally or from the db

This change creates Resource methods metadata_get and metadata_set to use
for reading and modifying resource data. This is a refactoring change only so
there should be no change in behaviour.

This change will help in the future with
Related-Bug: #1306743

Change-Id: I7cd87a071ac410a388d787f132c9aee194030714
Do not query database for every metadata_get

This change stores the rsrc_metadata locally when the Resource object
is created so that the database is not queried every time
metadata_get is called. There are some instances where the metadata
must come from the database (eg, polling for waitcondition signal) so
an optional refresh arg is added to metadata_get to force a database
refresh of the stored rsrc_metadata.

This results in one less sql query for every time metadata_get is called,
which will help the optimising effort for
Related-Bug: #1306743

Change-Id: Iad2d810c299347ae3b6a4a8329bbd314ee4b5c16
Refactor DB resource fetching from Resource to Stack

By moving this database call to the stack, this allows a future
change to adopt a loading strategy which avoids one sql call
per resource.

Change-Id: Ie29edaf3ffc0a332db421ad01edfa7445eb806e5
Merge "Fix status reason in events for deployment signals"