Currently we can only do a CURD action on a cron-trigger by name.
This patch refer to workflow implementation and re-encapsulate
DB API so that users can manage a cron-trigger by id or name.
Closes-Bug: 1684469
Change-Id: I9ff657b2604647e734b5539e9bd6a524a3a20efb
* It turns out that the behaviour of looping.RetryDecorator from
oslo.service is different than what was expected. See
https://bugs.launchpad.net/oslo.service/+bug/1718635 for
details. This patch replaces it with a similar decorator from
tenacity library.
Change-Id: I2d8a7f2b430e26991cc13a88ad33c1266c82d113
* Since scheduler has transactional logic we need to account for
cases when these transactions hit DB deadlocks. It is possible
just due to MySQL nature, it's recommended to always design
based on that. This patch decomposes one big scheduler method
that processes delayed calls into smaller methods so that we
could apply @db_utils.retry_on_deadlock decorator to repeat
transactions if they fail because of a deadlock in MySQL.
* Fixed taskk state update when we're assiging it to RUNNING.
In this case we can't set it to RUNNING if there any paused
child executions.
* Fixed the test for cascaded pausing which didn't account
non-atomicity of this operation
Closes-Bug: #1715589
Change-Id: Iffa0fb540a5705c587d71d30af6ab913b26d3952
Currently our API doesn't return any project info in many resources, like
execution, cron-trigger, workbook, etc. As a essential property in those
resources, it's really helpful for users to process resources if we
return project_id in resource endpoints.
Closes-Bug: 1707573
Closes-Bug: 1694398
Change-Id: I866d20cf1f5129b6249140063aa0836f63626767
In the file doc/source/user/dsl_v2.rst, the json format of
task publish result is not well formated, this change is to
pretty format the json code block
Change-Id: I783472c1d7c13cd7b6a464325cf7213abf3ac359
For sub-workflow executions this will be the ID of the initial workflow
execution. For example, given the following workflows.
workflows:
wf1:
tasks:
task1:
workflow: wf2
wf2:
tasks:
task1:
workflow: wf3
wf3:
tasks:
task1:
action: std.noop
When we start wf1, it calls wf2 which calls wf3. Currently, it is hard to
retrieve the full execution, including sub-workflow executions. This patch adds
the root_execution_id to the sub-workflows, so the execution for wf2 and wf3
have a root_execution_id that is the ID of the execution for wf1. The execution
for wf1 is the root execution, so root_execution_id is None. This basically
gives us a flat reference to the graph of workflow executions.
This change is useful as we can then expose it via the API and it makes
it easier and more efficient to find a full execution, including it's
sub-workflow executions.
Implements: blueprint mistral-root-execution-id
Change-Id: I24638812caa2e48e3c071925db5e552b21e15d47
This patchset adds the __init__.py file to mistral/tests/unit/expressions
to enable those tests to run, and updates the Jinja tests to include
the created_at attribute.
Closes-Bug: 1716452
Change-Id: I5c7af1cd4a2777764a2a46adf85129e4cb90e4d8
During some cases resp.content may have a context not in json format
and with 'None' in the resp.encoding. Need to properly handle this
situation and don't try to pass 'None' as an argument to decode.
Change-Id: Id87d650996f16b5ffab79d72413134a4c7fe9ca9
Closes-Bug: #1700608
devstack has removed screen completely in
I8c27182f60b0f5310b3a8bf5feb02beb7ffbb26a. This patch cleans up any
remaining references to screen from the Mistral devstack plugin.
Change-Id: I56d6fe2c6957f9a6b5cc30d7570288ceed8b9f35
Depends-On: I8c27182f60b0f5310b3a8bf5feb02beb7ffbb26a
* Added a call to clean up RPC clients into WSGIService start()
method to make sure that we reinitialize RPC in every child
API process. Otherwise, replies for synchornous RPC calls
don't get routed to the right client process (see bug
description)
* Mistral components engine, executor and event engine didn't
start properly because KombuServer.run() was implemented
w/o a new thread. This patch fixes it.
* The methods to get RPC clients like
mistral/rpc/clients.py:get_engine_client() wasn't synchronized
on the client instances. As a consequence, sometimes Mistral
created more than one instance of the same client (violation
of Singleton pattern). This patch fixes it by adding required
locking.
* Other style changes
Closes-Bug: #1714186
Closes-Bug: #1714929
Change-Id: I242c48df9811459321d1cd4b1d37ed35af0a013a
* Previously we thought that we can avoid locking task execution
when we process completion of an individual action inside
WithItemsTask. But that was wrong because even when we don't
need to control "concurrency" property we still can get a
situation when two different action completions will be
processed via scheduler and both will see all actions in state
SUCCESS (because scheduler handles it in a different later
transaction) and hence both will complete the task and run
tasks from "on-xxx" clauses. This patch makes WithItemsTask
always use locking.
* Added db_utils.retry_on_deadlock for
_scheduled_on_action_complete() method since it opens a new
DB transaction and can potentially end up in a dead lock (due
to MySQL nature)
Closes-Bug: #1715116
Change-Id: I6f34409e7182af3ca5b13c17e6d6fb4302f9efed
When Mistral services are configured with systemd, the services time out
on shutdown. The root cause is that each of the server thread is
assigned to a different instance of the oslo.service ServiceLauncher.
The ServiceLauncher can manage multiple server threads. When the server
threads are added to the same instance of the ServiceLauncher, SIGTERM
is handled properly for each server threads.
Change-Id: I8b739844f6073890324189aee028c0d7da3cc76e
Closes-Bug: #1714351
This patch will catch the DBEntityNotFoundError exception that is
raised when an AdHoc Action has an invalid base action defined. The
exception is converted to an InvalidActionException which will
halt the task/workflow and cause them to enter the ERROR state.
Change-Id: I115b8243641da100474e8c8b34a724978078978b
Closes-Bug: 1714548