Add a validation step to parameters schema

This enables validation of of the parameters section of the template, so
that operations like template-validate now return a proper error if
something is wrong.

Closes-Bug: #1265862
Co-Authored-By: cedric.soulas@cloudwatt.com
Change-Id: Ic5d67f18d7bc53fd3e4e765ca221e21be0b9546d
Make Keystone client pluggable

Similarly to how the engine client works, this makes it possible to
switch out the builtin keystone client with a custom - interface
compatible - plugin replacement.

Co-Authored-By: Anderson Mesquita <andersonvom@gmail.com>
Partial-Bug: #1274201
Change-Id: If14ff4b34b90f46d0f468fd669dcc2fdc36c8c97
Add Keystone V2 plugin

This adds the previous Keystone V2 client to be used as a plugin by
clouds that have not upgraded to V3 yet.  This replacement also raises
NotSupported exceptions in methods that are V3 only.

Co-Authored-By: Richard Lee <rblee88@gmail.com>
Closes-Bug: #1274201
Change-Id: I97d3fe7e5ff52250c699c9b470d114e53888ef15
Nova keypair validation breaks client plugins

Changes made to the nova keypair validation functionality break the
client plugin functionality.

Change-Id: Ia45db6dc369fe75520de03347e16b8e3f3c6ced8
Closes-Bug: #1280016
Modify stack_user_domain config option to take domain ID

It turns out that having the heat service user manipulate (get/create)
domains directly isn't a great idea, because although it works with
the default keystone policy.json, it won't work with the v3cloudsample
policy, which causes some of our tests to fail in the gate when migrating
the User/Access key resources.  Also not allowing the heat user to
create domains is probably more aligned with real deployment policy
expectations.

Note this requires the following devstack change, which will create the
required domain and update heat.conf appropriately:

https://review.openstack.org/#/c/73324/

Or for non-devstack deployments, the domain should be created via
python-openstackclient (which is the only CLI interface to the v3
keystone API, the keystoneclient shell is v2.0 only), e.g:

openstack --os-token <atoken> --os-url=http://<KS_IP>:5000/v3 \
    --os-identity-api-version=3 domain create heat

Change-Id: I2b058fd1b6361b04764111635f7ef7424cb73d7b
blueprint: instance-users
Add config options to specify stack domain admin

Adds config options to specify a username and password who can
administer the projects & users in the stack domain.  Note this
user must be a domain admin (have admin role in the domain)

Note this requires the following devstack patch:

https://review.openstack.org/#/c/76036/

Or for non-devstack deployments, the domain should be created via
python-openstackclient and heat.conf updated with the username and
password:

openstack --os-token <atoken> --os-url=http://<KS_IP>:5000/v3 \
    --os-identity-api-version=3 user create heat_domain_admin \
    --password <password> --domain <stack_user_domain id>

openstack --os-token <atoken> --os-url=http://<KS_IP>:5000/v3 \
    --os-identity-api-version=3 role add --user heat_domain_admin \
    --password <password> --domain <stack_user_domain id> \
    --domain <stack_user_domain id> admin

blueprint: instance-users
Change-Id: I8c5242d336e3fabafcd1930271408670af09fa0e
engine: allow stack_user_project users to retrieve stack

The current DB scoping (and service.py check) enforces retrieval of
stacks only when they match the request context project/tenant, but
with stack_user_project_id we must make an exception, since these
users will require access to the stack for a subset of operations,
which ones will be enforced via policy.json (not the engine)

Change-Id: I82bee14ae96e30653702b4bdb104a2b74cc20cd4
blueprint: instance-users
migrate StackUser base class to stack domain users

Migrates the user/credential interfaces to stack domain users,
so the user is created in the instance-user domain not the
domain of the user creating the stack.

Partial-Bug: #1089261
blueprint: instance-users
Change-Id: If4c57144a32050a8d0b145444a84896cce53908b
Make server resources use nova_utils.refresh_server()

Update Server, Instance, and CloudServer so that they use
nova_utils.refresh_server() instead of server.get().

Change-Id: Id65fabaa15c06ecf511c231888166eded00ba467
Move HOT version checking to HOTemplate class

This is HOT-specific code and does not belong in the Template class.

Change-Id: I95c5f1d57a8ad4f9f4b721742f2d45826b51e9aa
Allow Server name property to be updated

The patch will ensure the 'name' property updatable for the resource
OS::Nova::Server.

Change-Id: Iaf8569fc739b2e5f9b5011ecdd57af25f7b1f57d
Closes-Bug: #1279239
Always report the action in state_reason as engine encodes it

Presently the state_reason is a mix of upper and lower
case depending on where the state_reason is updated.  This
change defaults the state_reason's action text to upper case
in all cases.

Change-Id: I117d310858133d80675edd87d395c60764635eeb
blueprint: oslo-messaging
Implement OS::Neutron::ExtraRoute as /contrib

This codes aims to add support the ExtraRoute resources.

  * Neutron Router ExtraRoute as OS::Neutron::ExtraRoute
  * OS::Neutron::ExtraRoute is implemented in /contrib directory as plugin
  * The resource can be enabled by setting plugin_dirs property in heat.conf

Co-Authored-By: Kevin Benton <kevin.benton@bigswitch.com>
(from https://review.openstack.org/#/c/41044/)

Change-Id: I27dabe42e6c96a475aa2f31b091616c89eef83a7
Implements: blueprint extraroute-as-contrib
Merge "Modify stack_user_domain config option to take domain ID"
Merge "Move HOT version checking to HOTemplate class"
Merge "Add config options to specify stack domain admin"
Merge "Add a validation step to parameters schema"
Merge "engine: allow stack_user_project users to retrieve stack"
Merge "migrate StackUser base class to stack domain users"
Merge "Implement OS::Neutron::ExtraRoute as /contrib"