Introduce execution events and notification server and plugins for
publishing these events for consumers. Event notification is defined per
workflow execution and can be configured to notify on all the events or
only for specific events.
Change-Id: I9820bdc4792a374dad9ad5310f84cd7aaddab8ca
Implements: blueprint mistral-execution-event-subscription
Using the package name to identify the top module name can cause issues
if the package is renamed for any reasons. Hard coding the top module
ensures more resiliency towards these types of accidental failures
and provides an obvious mapping for the file names.
Change-Id: I9542ba8f01f57b1b3473185c42d95d99ad1e8435
Now to perform some action mistral gets its definition from
the database first. It's not really optimal, because if there are
a lot of similar action calls, mistral will reread the same data
from db. It increases the whole execution time and the load on the
database.
To improve the performance it's suggested to cache read definitions
and take them from the cache instead of the database in the subsequent
times.
Cache ttl can be configured with ``action_definition_cache_time``
option from [engine] group. The default value is 60 seconds.
Change-Id: I330b7cde982821d4f0a06cdd2954499ac0b7be37
Note: This is an update to I9060253bc416be28af4ef81f3edf694059d92066,
which almost worked but due to a race condition with config loading
the default value may have been used. This delays the decorator
execution to allow the config to be fully loaded.
The cron_trigger subsystem in Mistral queries the database every second
to look for triggers that require execution. This can be very wasteful
if your deployment only has cron triggers that run infrequently (every
hour or day etc.). Letting operators configure this value reduces the
load and allows the cron triggers to be useful in more scenarios.
Operators do need to be aware that this configuration would limit the
frequency of execution. For example, if the value is set to 600 then cron
triggers configured to run every minute will only run every 10 minutes.
Related-Bug: #1747386
Change-Id: Ia12dcf7fa6b1784be226d223eb89b114c8e4b4f5
While printing the output of a execution
size of output_on_error is not considered
with the field_size_limit_kb
This patch udpates the function to include
the logical calculation of total size limit
Closes-Bug: #1690316
Change-Id: Icab63d147f580b8d72d8c02b3d9261fd64d3438a
If an invalid tag section was specified, Mistral would throw a 500,
with no useful error message. This makes the tags get checked and
throws a proper error if so.
Change-Id: If2ae69ef76a857bcafe1e4b3d72956c6deeeea09
Closes-Bug: #1747950
The cron_trigger subsystem in Mistral queries the database every second
to look for triggers that require execution. This can be very wasteful
if your deployment only has cron triggers that run infrequently (every
hour or day etc.). Letting operators configure this value reduces the
load and allows the cron triggers to be useful in more scenarios.
Operators do need to be aware that this configuration would limit the
frequency of execution. For example, if the value is set to 600 then cron
triggers configured to run every minute will only run every 10 minutes.
Related-Bug: #1747386
Change-Id: I9060253bc416be28af4ef81f3edf694059d92066
* It was broken when we were adding the "wf_ex_id" parameter to
Engine.start_workflow()
* Fixed the test that checks how triggers start workflows
* Other minor changes
Change-Id: Ida361a53ffdb5426a39d276d567391d25261fb7f
This patch changes the call into oslo_config to pass the string
containing the version instead of passing the version module.
Change-Id: I698d7206c195f1762dfbadb78c599c60be7f310b
Fixes-bug: 1717869
This proposal will add a couple more scenarios to the unit
test for the source_execution option.
Related-Bug: #1745962
Change-Id: If5b846c8e45df9e20c2d5da099bddcbf9432d797
The description of the param 'content_type' doesn't read well,
I think 'Content-Type of the response' is better.
Change-Id: Idfdedf2cfc1abf6ab6f6980114c6d7d00c557afc
The oslo.log (logging) configuration library provides standardized
configuration for all openstack projects. It also provides custom
formatters, handlers and support for context specific logging (like
resource id's etc).
I think it's better to use the common logging module.
Change-Id: I3baefd043a557417e8317a80d57cc5a4a48ccc08
It shall be possible to specify timeout for Mistral actions in order
to cancel some long-performed action so that to provide predictable
execution time for client service.
Currently Mistral allows configure timeout on task and automatically
changes task status to error. However mistral don't interrupt action
execution.
We need Mistral to terminate timed out action execution, because there
might be the following issues:
* several the same action executions can run at the same time breaking
data consistency
* stale action executions may lead to the massive resources
consumption (memory, cpu..)
Change-Id: I2a960110663627a54b8150917fd01eec68e8933d
Signed-off-by: Vitalii Solodilov <mcdkr@yandex.ru>
Alphabetically order your imports by the full module path.
Organize your imports according to the Import order template and
Real-world Import Order Examples below.
{{stdlib imports in human alphabetical order}}
\n
{{third-party lib imports in human alphabetical order}}
\n
{{project imports in human alphabetical order}}
\n
{{begin your code}}
Change-Id: I16e97549a7ae6ddedc07e76dba72236460060650