Hide warning for old style attribute schema test

Change-Id: I6a3d0464bffe65f8ef7ab9006882cbeaa03cc20d
parser.Stack add use_stored_context option

Add an option to switch to a context based on the user_creds data
at constructor time, which allows a cleaner interface for selecting
the stored context than creating it before creating the Stack object.

Partial-Bug: #1306294

Change-Id: I44df4e142dfbba1e70199b0d8f14c910f028a0f1
Convert service.py to use_stored_context

Related-Bug: #1306294

Change-Id: Ia75126ad77e6cad187a1953c2fb43eceb50299f2
Remove test_autoscaling _stub_validate

The _stub_validate is stubbing the wrong thing, it stubs the top-level
validate which hides the fact that the image validation fails for all
delete operations, where the validation always fails because the call
to glance is not correctly stubbed.

Partial-Bug: #1306294

Change-Id: Ibe3480f5ff358c00a4ad3c2df9b6cd7d15bda71d
test_autoscaling refactor suspend/resume stubbing

Rework to encapsulate the suspend/resume stubbing in functions and add a
stub of the image validation, which is required because the properties
get revalidated when we create the events associated with the state
transition (ref bug #1324102).

With the current keystoneclient mocking this is not visible in the
tests because the error creating the client to do the validation is
obscured by the fact that the Event constructor tolerates a validation
error and the error creating the client is just treated as an unexpected
validation error by the CustomConstraint code.

Moving to a model where clients.keystone() is consistently mocked
exposes the fact that we will try to connect to glance on suspend when
the event is created if the validation is not correctly stubbed.

Partial-Bug: #1306294

Change-Id: I001d3a432397d4cdfaa62145228aad7eaf051b98
tests add stub_keystoneclient to base test class

Add convenience function to allow easy stubbing of keystoneclient
in all tests where explicit control and verification is not required.
This is a precursor to making all clients use the auth_token property
from keystoneclient (instead of using the context auth_token in
preference) such that trust tokens can be refreshed before expiry.

Partial-Bug: #1306294

Change-Id: I9ba4595b8750ff769e76972cc30b55a68253e76d
engine.clients always use keystoneclient auth_token

Always get the token from keystoneclient, even if there is one in
the request context, as if the context contains a username and
password, there is the possibility the keystoneclient auth_token
may be a reissued token which should be preferred to the one in
the context which may have expired.

Change-Id: Icbce9ae7a8ff7cad5eadec3de4f69b977949c265
Partial-Bug: #1306294
Don't set context auth_token in heat_keystoneclient

Now that all clients refer directly to the auth_token in the auth_ref
there's no need to set the auth_token in the context when consuming
a trust.

Change-Id: I2fe58de7b950a65672b490f1769c88dedda3895b
Partial-Bug: #1306294
Remove heat_keystoneclient roles filtering workaround

The currently required version of keystoneclient contains the logic
to filter by name so remove the interim workaround

Change-Id: I7bd7657031e00d2db9376dbf587253a3b3be5a9d
Hide deprecate warnings for metadata tests

attribute metadata is deprecated, the deprecate
warnings in tests should be hidden

Change-Id: Ia7c04a8edb55fb5e2ef27a10da72804d4af75991
Merge "parser.Stack add use_stored_context option"
Merge "Convert service.py to use_stored_context"
Merge "Remove test_autoscaling _stub_validate"
Merge "test_autoscaling refactor suspend/resume stubbing"
Merge "tests add stub_keystoneclient to base test class"
Merge "engine.clients always use keystoneclient auth_token"
Merge "Don't set context auth_token in heat_keystoneclient"
Fix race condition deleting in-progress stack

If we call stack_delete on a stack with an operation in progress, we kill
any existing delete thread that is running. However, we don't wait for that
thread to die before starting a new thread to delete the stack again. If
any part of the cleanup operation in the old thread (i.e. handling of the
GreenthreadExit exception) causes a context switch (which is likely), other
threads can start working while the cleanup is still in progress. This
could create race conditions like the one in bug 1328983.

Avoid this problem by making sure we wait for all threads in a thread group
to die before continuing. (Note that this means the user's API call is
blocking on the cleanup of the old thread. This is sadly unavoidable for
now, but should probably be fixed in the future by stopping the old thread
from the new delete thread.)

This was suggested earlier, but removed without explanation between
patchsets 11 and 12 of I188e43ad88b98da7d1a08269189aaefa57c36df2, which
implemented deletion of in-progress stacks with locks:
https://review.openstack.org/#/c/63002/11..12/heat/engine/service.py

Also remove the call to stack_lock_release(), which was a hack around the
fact that wait() does not wait for link()ed functions - eventlet sends the
exit event (that wait() is waiting on) before resolving links. Instead, add
another link to the end of the list to indicate that links have all been
run. This should eliminate "Lock was already released" messages in the
logs.

Change-Id: I2e4561cbe29ab10554da67859df8c2db0854dd38
Remove unused generate_request_id

The heat.common.context module has an unused function to generate
the request id, this is now handled by the underlying oslo module
so can now be removed.

Change-Id: Iac5c2f8105dc88af5cae6937a68e1422694afe24
Merge "Hide deprecate warnings for metadata tests"