Service available group already exists.Therefore we don't need to
register this group here again.
Change-Id: I570cb7c1d2e13318a102b9f01a85fd24ffb89f9a
Closes-Bug: #1621036
Updates the Mistral server to accept the service catalog
from the client request. This enable the server to cooperate
with Keystone Identity V2 and V3 at the same time.
Change-Id: I7ca2aace4d5095828e5053af6965b833109d338a
Closes-Bug: #1612705
Depends-On: I86fa58de00d01c89e4bbc21dbe128f1306e2a1bf
Signed-off-by: Andras Kovi <akovi@nokia.com>
This test class doesn't fully test event engine functions, because
we can not send real notifications to the internal message queue to
trigger the specified workflows.
So, before notification is supported in Mistral, we can only test the API
functions.
Change-Id: I4289dac17f19cd2ce3c214c5625f3b7d9db605de
Implements: blueprint event-notification-trigger
* Now when we query a collection of objects from DB we don't
use paginated query if query set is not limited
* In case of paginated query we now always insert "id" into
sort keys to avoid possible looping for multiple paginated
querying
* Minor cosmetic changes
Change-Id: Ie4707b04a97c7fa17dcf278c74e2e852346ac33c
This patch contains the Mistral database and db_api changes
required for the event triggers.
Change-Id: Ib930ef8aac3792ed415e2817f67226962e6f7a92
Implements: blueprint event-notification-trigger
Co-Authored-By: Lingxian Kong <anlin.kong@gmail.com>
ServersClient class doesn't exists in tempest.clients module, so
the error below occurs for unit test SSHActionsTestsV2:
File "/opt/stack/new/mistral/mistral_tempest_tests/tests/base.py",
line 78, in resource_setup
AttributeError: 'module' object has no attribute 'ServersClient'
We should use service clients initialized in tempest credential setup.
Change-Id: I09dea2f596abab9987221ff9d79a065d269f73a9
* Introduced new class Workflow that manages life-cycle of running
workflows and is responsible for managing workflow persistent state
* Moved all workflow level logic to workflow handler and Workflow class
* Changed semantics if how workflows start errors are handled.
Previously, in case of invalid user input Mistral engine would store
information about error in "state_info" field of workflow execution
and bubble up an exception to the user. This approach was incorrect
for a number of reasons including broken semantics: if an exception
was raised due to invalid input it's normal to expect that system
state has not changed. After this refactoring, engine only raises
an exception in case of bad user input. That way behavior is
consistent with the idea of exceptional situations.
* Fixed unit tests in according to the previous point
* Fixed a number of logical issues in tests. For example, in
test_default_engine.py we expected one type of errors (e.g. env not
found) but effectively received another one (invalid input).
Partially implements: blueprint mistral-engine-error-handling
Change-Id: I09070411fd833df8284cb80db69b8401a40eb6fe
* Introduced class hierarchies Task and Action used by Mistral engine.
Note: Action here is a different than executor Action and represents
rather actions of different types: regular python action, ad-hoc
action and workflow action (since for task action and workflow are
polymorphic)
* Refactored task_handler.py and action_handler.py with Task and Action
hierarchies
* Rebuilt a chain call so that the entire action processing would look
like a chain of calls Action -> Task -> Workflow where each level
knows only about the next level and can influence it (e.g. if adhoc
action has failed due to YAQL error in 'output' transformer action
itself fails its task)
* Refactored policies according to new object model
* Fixed some of the tests to match the idea of having two types of
exceptions, MistralException and MistralError, where the latter
is considered either a harsh environmental problem or a logical
issue in the system itself so that it must not be handled anywhere
in the code
TODO(in subsequent patches):
* Refactor WithItemsTask w/o using with_items.py
* Remove DB transaction in Scheduler when making a delayed call,
helper policy methods like 'continue_workflow'
* Refactor policies test so that workflow definitions live right
in test methods
* Refactor workflow_handler with Workflow abstraction
* Get rid of RunExistingTask workflow command, it should be just
one command with various properties
* Refactor resume and rerun with Task abstraction (same way as
other methods, e.g. on_action_complete())
* Add error handling to all required places such as
task_handler.continue_task()
* More tests for error handling
P.S. This patch is very big but it was nearly impossible to split
it into multiple smaller patches just because how entangled everything
was in Mistral Engine.
Partially implements: blueprint mistral-engine-error-handling
Implements: blueprint mistral-action-result-processing-pipeline
Implements: blueprint mistral-refactor-task-handler
Closes-Bug: #1568909
Change-Id: I0668e695c60dde31efc690563fc891387d44d6ba
While running tempest tests over https, warnings
are shown for unverified HTTPS request beacause
by default urllib3 don't verify ssl certificates.
So now, certification validation warnings have been
disabled.
Change-Id: I0e99af8364e262baa37a56b0a8846abde3a8d2b0
Closes-bug: #1570451
This patch fix the dir_path that helps to get the directory of
Mistral resources.
Without this patch, this is what we get when running Tempest:
IOError: [Errno 2] No such file or directory:
'/usr/lib/python2.7/site-packages/mistral_mistral/tests/resources/openstack/action_collection_wb.yaml'
With this patch:
/usr/lib/python2.7/site-packages/mistral/tests/resources/openstack/action_collection_wb.yaml
This path is correct and Tempest runs successfully.
Change-Id: Ie4bd3db8a4e729f7937a6f3c099d7c25abffcb1b
Closes-Bug: #1568413
The switch to tempest.lib in tempest is done
in https://review.openstack.org/#/c/283755/
mistral should use tempest.lib instead of tempest-lib because
tempest-lib will be deprecated.
Change-Id: I202d82be0b276886433b0ceeb9c17e1707232f68
Depends-on: I4da5e807914ce8a11b201aad765d827cb9bf9d9a
when workflow execution is created by workflow_id
'workflow_name' key error was raised. Now 'workflow_name'
is extracted from dictionary using get() function.
Change-Id: I5a648742b2653818d3bc4d4025ce1fe0b73a2d24
Closes-bug: #1549047
This patch allows the Mistral actions to be run synchronously from
the Mistral CLI.
When a Mistral action is run synchronously using the Mistral CLI
'run-action' command, it does not complete successfully. This is due
to the Mistral API server handling requests on a single thread.
The 'run-action' command performs a REST POST call to the
ActionExecution RestController in the API server. That in turn calls
back into the python-mistralclient which then performs another REST
call back to the appropriate REST controller to actually run the
action requested. That call hangs since the requests are handled on
a single thread because the first POST has not completed yet.
Eventually the RPC call between the engine and the executor servers
times out, and the 'run-action' command fails.
This patch changes the Mistral API server so that requests are
handled in separate threads.
Added a new functional test to the tempest test package to test
synchronous action execution of a mistral action from within
mistral.
Change-Id: I8e06d3ef6aab4b2009a8fff4aa4d1acc118eee3f
Implements: blueprint mistral-mistral-actions
All the changes has been merged to mistral_tempest_tests.
Also scrits has been changed.
Change-Id: I6c514a3c75f1b6e3b94b0e9b0e542697b68d9a02
Partially-Implements: blueprint mistral-tempest-plugin
This file contains information about how
to run mistral tests from tempest.
Change-Id: I15498921ecf8f111099dc607731f567321fbfa13
Partially-Implements: blueprint mistral-tempest-plugin