This patch fixes 128 unit test failures under Python 3.12 when
building the Debian package under Unstable. Without this patch,
I'm getting:
Traceback (most recent call last):
File "/usr/lib/python3.12/threading.py", line 1073, in _bootstrap_inner
self.run()
File "/usr/lib/python3.12/threading.py", line 1010, in run
self._target(*self._args, **self._kwargs)
File "/<<PKGBUILDDIR>>/mistral/services/legacy_scheduler.py", line 152, in _loop
random.Random().randint(0, self._random_delay * 1000) * 0.001
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3.12/random.py", line 336, in randint
return self.randrange(a, b+1)
^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3.12/random.py", line 312, in randrange
istop = _index(stop)
^^^^^^^^^^^^
TypeError: 'float' object cannot be interpreted as an integer
Change-Id: Ia85ea13923216d090ef1e4deee7840e70f9185b4
hacking 3.0.x is too old.
Also remove the note about pip's behavior which was already fixed in
recent versions.
Change-Id: I65d350943649c3346ed5741631c01724ddd256ef
We have no way to determine whether the workflow definition has
changed or not.
This complicates the work with Mistral for external services.
A 'checksum' field has been added to workflow_definitions_v2
to solve this issue.
Implements: blueprint mistral-add-checksum-field-to-wf-definition
Change-Id: I99d095c6c74c62f134aedfa3a63308a0712db38d
After this patch, user can update logging format to include root_execution_id in logs, which will be helpful to find and debug logs related to specific workflow execution.
- Logs about creation and status changes of Mistral entities(execution,
task, action execution, etc) are changed to INFO log level.
- User can update logging_context_format_string to include root_execution_id in logs.
Implements: Implements: blueprint improve-mistral-loggers
Change-Id: I54fe058e5451abba6ea7f69d03d498d78a90993e
When creating a periodic workflow execution from a cron trigger, the
description field was filled with info like cron trigger ID, name, etc.
The cron trigger name can be set by user and is then injected in the
description field.
Beside the fact that this is not useful, it may also be dangerous.
The purpose of this patch is to remove the name from the description so
that the lenght of description field is not user dependant anymore.
Signed-off-by: Arnaud Morin <arnaud.morin@ovhcloud.com>
Change-Id: I326400a4a04fba71ccc90545909212a41d6b3b13
The following arguments of the RequestContext class are deprecated
since oslo.context 2.18[1].
user : renamed to user_id
tenant : renamed to project_id
domain : renamed to domain_id
user_domain : renamed to user_domain_id
project_domain: renamed to project_domain_id
This change updates arguments used accordingly.
[1] d78cf592e1e3e7aa0fc99bfdd655e82f5c44dfe3
Change-Id: I24a8963d112a24674ad5699685118d019ef1ed56
* Reworked /code_sources and /dynamic_actions API endpoints to
simplify them. For now they don't work with multiple objects and
they are consistent with other endpoints. If needed, we'll add
support for multiple objects (i.e. adding multiple dynamic actions
with a single request) later in a backwards compatible manner.
* Simplified unit tests.
* Got rid of services/*.py modules since they didn't do anything
useful. They were just wrappers around DB API calls.
Change-Id: Ib5a53f1f1a185f0395ffae1ab0c401633fcdd0fc
* Style improvements to make sure the code is compliant with the
coding guidelines
* Fixing small but important things like the mismatch between the
sinatures of the methods find_all() in the DynamicActionProvider
class and the base ActionProvider interface.
* Improved the tests.
* Simplified the implementation of DynamicActionProvider.
Change-Id: Idbfb15b4c3bb415e7fa9c7ece27eabfe674b6059
* added dynamic actions:
these actions are created and modified in runtime,
each action needs a code source to be imported from and a
class name.
- there are 2 new endpoints:
- /v2/code_sources/:
used to add new code sources to mistral.
- /v2/dynamic_actions/:
used to add dynamic actions to mistral in runtime
- a new Action provider (DynamicActionProvider) was added:
it provides the actions created from the dynamic actions api.
Change-Id: I9fe8c28ffdef71016d9dc13aea60a288c8ebaa0a
Signed-off-by: ali <ali.abdelal@nokia.com>
* This patch refactors Mistral with the action provider concept
that is responsible for delivering actions to the system. So
it takes all the burden of managing action definitions w/o
having to spread that across multiple subsystems like Engine
and API and w/o having to assume that action definitions are
always stored in DB.
* Added LegacyActionProvider that represents the old way of
delivering action definitions to the system. It pretty much just
analyses what entries are configured in the entry point
"mistral.actions" in setup.cfg and build a collection of
corresponding Python action classes in memory accessible by names.
* The module mistral/services/actions.py is now renamed to
adhoc_actions.py because it's effectively responsible only for
ad-hoc actions (those defined in YAML).
* Added the new entry point in setup.cfg "mistral.action.providers"
to register action provider classes
* Added the module mistral/services/actions.py that will be a facade
for action providers. Engine and other subsystems will need to
work with it.
* Other small code changes.
Depends-On: I13033253d5098655a001135c8702d1b1d13e76d4
Depends-On: Ic9108c9293731b3576081c75f2786e1156ba0ccd
Change-Id: I8e826657acb12bbd705668180f7a3305e1e597e2
* These workflows are openstack workflows and should be in mistral-extra
* Rename the function name to register_preinstalled_workflows
* Rename then function name to register_preinstalled_actions
Change-Id: I80fc1dfe4ec5e81b1b5163c9771eea5a49432f88
Depends-On: https://review.opendev.org/#/c/709970/
Depends-On: https://review.opendev.org/#/c/710024/
* Method _create_action_execution() for AdHocActin didn't have
the right signature. It was missing the argument "namespace" and
failed under some conditions. This patch does some refactoring
to preserve the target namespace during action init time. For
regular python actions it's just taken from it's action definition
object. For ad-hoc actions it is taken from its definition also
but it has to do it separately because it extends the class
PythonAction passing a base action definition into it as a parameter
of the initializer (so that extracts the namespace of the base action).
The benefit of preserving a namespace value during init time is that
it becomes available for the entire instance life-span, not only for
the method _create_action_execution().
* Style changes (blank lines, indentation, formatting).
Change-Id: I84d1cd0fb4a746197ad890276f654cd12455603e
* The field "key" of the DelayedCall class must be set to the right
value. It allows to significantly optimize performance of workflows
with "join" tasks. However, it was broken during the refactoring
in the summer of 2019. This patch fixes it.
* Added another profiler trace decorator.
Closes-Bug: #1861988
Change-Id: I247b674d8a358795871cfa87bcdf29f4857ca2d8
* It turns out that osprofiler wasn't initialized properly for
threads in which scheduler runs its jobs. So profiling simply
didn't work for this threads and lots of important info didn't
get to the profiler log. This patch fixes it.
* When evaluating a YAQL expression, sometimes we get a huge result
value that we always put into the debug log. In practice, it doesn't
make much sense and, moreover, it utilizes lots of CPU and disk
space. It's better shrink it to some reasonable size that would
allow to make necessary analysis, if needed.
* Other minor style fixes according to the Mistral coding guidelines.
Change-Id: I3df3ab96342c456429e20a905615b90bcb94818d
Update to PyYAML 5.1 to be able to turn off key sorting
in workflow definitions. We should not change user's data
until user asks to.
Change-Id: I888008ac8f9c12bd92a9bd72bd7c276a11827847
Closes-Bug: #1815515
Signed-off-by: Oleg Ovcharuk <vgvoleg@gmail.com>
added namespace for the actions, actions can have the same name if they
are not in the same namespace, when executing an action, if an action
with that name is not found in the workflow namespace or given
namespace mistral will look for that action in the default namespace.
* action base can only be in the same namespace,or in the
default namespace.
* Namespaces are not part of the mistral DSL.
* The default namespace is an empty string ''.
* all actions will be in a namespace, if not specified, they will be
under default namespace
Depends-On: I61acaed1658d291798e10229e81136259fcdb627
Change-Id: I07862e30adf28404ec70a473571a9213e53d8a08
Partially-Implements: blueprint create-and-run-workflows-within-a-namespace
Signed-off-by: ali <ali.abdelal@nokia.com>
* Previously action hearbeats didn't work in case of using local
executors because the component responsible for sending heartbeats
was started by the executor RPC server which doesn't make sense to
initialize for a local executor. This patch refactors the code
so that now heartbeats get sent for any type of executors. For
local executors it is also useful because a cluster node that
runs an engine and a local executor may also crash. With this
change, remaining cluster nodes will be able to understand that
the action will never complete and one of them will time it out.
If all is fine with the node where the local executor is running
then heartbeats will be sent normally and the action won't time
out. Before this change, in case of local executors a long running
action would always time out after a configured amount of time
(by default, 60 mins) just because local executors never sent
heartbeats.
* Made a lot of renamings to clearly see what component is
responsible for.
* Wrote the tests that check the heartbeat sender, both positive
and negative scenarios for local and remote executor types.
Closes-Bug: #1852722
Change-Id: I4d0fdff54de9bee70aeaf10a4ef483ad7000840b
* Moved away from using Oslo periodic tasks in the action execution
reporter since in this case they don't make the code more readable.
Also, now it is symmetric with other similar components like action
execution checker.
* Refactored action execution checker w/o using classes since having
many instances of it doesn't make sense.
* Small style changes
Change-Id: I9a97c40222e8dc4870c9b6a7c5f5e3c14f37bdd6
* Added a configuration option to the expiration policy
to filter out workflow states.
Closes-Bug: #1796627
Change-Id: Ife49e6da1d7d52a3f50f1628d808d4c65a22cad9
* For the sake of the service performance, it may make sense to
disable validation of the workflow language syntax if it is
affordable for a particular use case. For example, if all
workflows are auto-generated by a 3rd party system and tested
thoroughly (either by running them with Mistral or at least
validating them via the special Mistral endpoint) then we can
safely disable validation of the language syntax when uploading
workflow definitions. For production systems it makes a big
difference if workflow texts are large (thousands of tasks).
This patch adds the boolean parameter "skip_validation" for API
requests like "POST /v2/workflows" to disable validation, if
needed, and the new configuration property "validation_mode"
to set a desired validation mode.
The option is an enumeration and has the following valid values:
1) "enabled" - enabled for all API requests unless it's
explicitly disabled in the request itself
2) "mandatory" - enabled for all API requests regardless
of the flag in the request
3) "disabled" - disabled for all API requrests regardless
of the flag in the request
"mandatory" is choosen as the default value for this new
property to keep compatibility with the previous versions.
* Minor style changes.
Closes-Bug: #1844242
Change-Id: Ib509653d38254954f8449be3031457e5f636ccf2
* Changed method get_scheduled_jobs_count() in the Scheduler
interface to has_scheduled_jobs(). In fact, the callers
always need to compare the number of jobs with 0, i.e.
to see if there are any jobs or not. But more importantly,
this semantics (returning just boolean) allows to make a
good optimisation for DefaultScheduler and avoid DB calls
in a number of cases. Practically, for example, it saves
several seconds (5-6) if we run a workflow with 500 parallel
no-op tasks that are all merged with one "join" task. Tested
on 1 and 2 engines.
* Added test assertions for has_scheduled_jobs()
* Other minor chagnes
Change-Id: Ife48d9e464114fd60a08707d8f32f847a6f623c9
Instead of making a lot of single requests for deleting stored delayed
calls, we can use bulk requests.
Change-Id: Ia2a6462d72f31df18a9811329672eae7f60d160f
* After this patch we can switch scheduler implementations in the
configuration. All functionality related to scheduling jobs is
now expressed vi the internal API classes Scheduler and
SchedulerJob. Patch also adds another entry point into setup.cfg
where we can register a new scheduler implementation.
* The new scheduler (which is now called DefaultScheduler) still
should be considered experimental and requires a lot of testing
and optimisations.
* Fixed and refactored "with-items" tests. Before the patch they
were breaking the "black box" testing principle and relied on
on some either purely implementation or volatile data (e.g.
checks of the internal 'capacity' property)
* Fixed all other relevant tests.
Change-Id: I340f886615d416a1db08e4516f825d200f76860d
In case we load definition of one workflow, there is no need to convert
it to yaml and back.
Change-Id: Ia7fb914843e56650c8f6ff5e8c16d1b57001c0fc
Signed-off-by: Oleg Ovcharuk <vgvoleg@gmail.com>
In case of creating/updating multiple workflows from one yaml,
we should not save the whole input to each workflow.
Closes-Bug: #1792975
Change-Id: I724c041ab3441805fcfa2cfc4a50afd774998cc7
Signed-off-by: Oleg Ovcharuk <vgvoleg@gmail.com>
* Removed using scheduler from action execution heartbeat checker
in favor of regular threads.
* Added the new config options "batch_size" under [action_heartbeat]
group to limit a number of action executions being processed during
one iteration the checker.
* Added a test checking that an action execution is automatically
failed by the heartbeat checker.
Closes-Bug: #1802065
Change-Id: I18c0c2c3159b9294c8af96c93c65a6edfc1de1a1
* action_queue module is replaced with the more generic
post_tx_queue module that allows to register operations that must
run after the main DB transaction associated with processing a
workflow event such as completing action.
* Instead of calling workflow completion check from all places
where task may possibly complete, Mistral now registers a post
transactional operation that runs after the main DB transaction
(to make sure at least one needed consistent DB read) right
inside the task completion logic. It reduces clutter significantly.
* Workflow completion check is now registered only if the just
completed task may lead to workflow completion, i.e. if it's the
last one in a workflow branch.
* Join now checks delayed calls to reduce a number of join
completion checks created with scheduler and also uses post
transactional queue for that.
Closes-Bug: #1801872
Change-Id: I90741d4121c48c42606dfa850cfe824557b095d0
A previous patch allows to make multiple event_engines to listen
to a single queue, but the RPC calls on CRUD are still synchronous
This patch modifies the calls and broadcasts them on all the event
engines allow them to modify each independent listeners.
Closes-Bug: #1715848
Change-Id: Ia37831a03993f5a1bf980d62344d25377062788d
* This fix drastically improves performance since it eliminates
an unnecessary update of the workflow execution object when
processing "on_action_complete" operation. W/o this fix
all such transactions would have to compete for the workflow
executions table that causes lots of DB deadlocks (on MySQL)
and transaction retries. In some cases the number of retries
even exceeds the limit (currently hardcoded 50) and such tasks
can be fixed only with the integrity checker over time.
See the code comment in the "dispatcher.py" module that explains
why this specific change eliminates the update of the workflow
execution object.
* Style changes in api.py and aciton_execution_checker.py
Closes-Bug: #1790079
Change-Id: I08cb561e252d31e35fcfb61984d87a7bfc387a4d
Currently when we get a specification using the instantiate_spec function,
we always validate their schema and semantics over and over again.
To prevent it we add new validate parameter to a Spec class.
The validate parameter must be True when we create a workflow, workbook
or action using a mistral-api. In all other cases, it must be False.
Change-Id: Ia450ea9635bc75c204fe031cfeeab154f1d03862
Closes-Bug: #1738769
Signed-off-by: Vitalii Solodilov <mcdkr@yandex.ru>
This patch brings namespace support to workbooks.
Namespace of the workbook is inherited by workflows.
Implements: blueprint mistral-namespace-for-actions-workbooks
Change-Id: I2c66b3961915f0f35a9c468eb6dd0c0c70995234
Currently if the API is stopped for a length and restarted the crontrigger
jobs will have their next execution in the past and will do a catchup
running a lot of times. That happens because the next execution is
calculated based on the first time it was executed. This change makes it be
the next execution time be the max of the calculated time and utcnow so
that if the server is lagging we keep uptodate with the calculated next
execution times.
Change-Id: I05b35261b1adbe17a1b0316eee95da12634c3978
Closes-bug: 1719882
Vadim Zelenevsky