heat_keystoneclient ensure admin client respects SSL options

The SSL related fixes merged under blueprint clients-ssl-options
and bug #1213122 missed the transient client created by
create_trust_context, so add the required options to
service_admin_creds, such that any client created using the
service admin credentials will use SSL if configured to do so.

Change-Id: Iab25c5ee6ec5cba9aaaccb93ce4e680e2f9cd9ac
Related-Bug: #1213122
heat_keystoneclient: Move v3 path logic to constructor

Work out the v3 path in the constructor and set it as a variable
as it is needed in more than one place so it's better to just
do this once.

Change-Id: I6f8e887c0eeacd3b2e78a71e36fcd93850a144c2
heat_keystoneclient: abstract admin_client to a property

To make the connection to keystone with admin credentials reusable
store the admin client object at the class level rather than local
to create_trust_context.  This will avoid the overhead of
getting two authenticated clients when other admin operations are
necessary.

Change-Id: Iaa043b829778f71d03e64a78ccb3f51eadfb3fba
blueprint: instance-users
Store files in the raw_template table

With the get_files intrinsic function, the files data will need to be
available at any time. This change adds a files column to the raw_template
table and saves/loads files from Template class.

Change-Id: I9fd705326ecfe7ca9e00624c67e7dd1965f95a96
Update heat.conf.sample for python-keystoneclient 0.5.0

python-keystoneclient 0.5.0 added a new oslo.config option:

 enforce_token_bind=permissive

Change-Id: Icffdef259be276c6c298ad3a5be8aa6c851f49f3
Updated from global requirements

Change-Id: I138166d61366c57bc772aaa283e9067d2181863e
Merge "heat_keystoneclient ensure admin client respects SSL options"
Merge "heat_keystoneclient: Move v3 path logic to constructor"
Merge "heat_keystoneclient: abstract admin_client to a property"
Resource type for software configuration

    Implementation of the SoftwareConfig resource. Some notes on the implementation:
    * This is a simple wrapper over the REST API, and is essentially
      just for defining data which gets stored.
    * SoftwareConfig will always be UpdateReplace, and the REST entity
      is immutable.
    * OS::Heat::SoftwareConfig will sometimes be used in a template directly
      and sometimes inside a resource provider template which
      defines CM-tool specific properties and aggregates the result into
      the OS::Heat::SoftwareConfig config property.

Implements: blueprint hot-software-config

Change-Id: I7350c31ec59d152751c6aa7d811a91e1df62e89d
A multipart cloud-init resource based on SoftwareConfig

This simple resource allows a multipart mime message to be built out
of an assembly of other SoftwareConfig resources. These assembled resources
will generally be a mixture of OS::Heat::CloudConfig and
OS::Heat::SoftwareConfig resources.

The full multipart content is fetched and stored during resource create.
This is safe since SoftwareConfig data is immutable once created.

Because cloud-init is boot only, this resource won't be used with
a SoftwareDeployment resource, also it will not have inputs or outputs.

Instead, a server's user_data can contain this resource via get_resource
when user_data_format is SOFTWARE_CONFIG.

Implements: blueprint cloud-init-resource

Change-Id: Id72f6ccb6802d654a1dec31f37fb0bcab0e36843
RPC service for software config/deployment

These RPC service methods are wrappers over the DB API.

Implements: blueprint hot-software-config-rest
Change-Id: I2c2e53f633cca30533b9190ebccc0d6eddcfb21f
Merge "Store files in the raw_template table"
Merge "A multipart cloud-init resource based on SoftwareConfig"
Merge "RPC service for software config/deployment"
Merge "Updated from global requirements"