* 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
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
hardik