In a patched environment, time.sleep will be eventlet.sleep, so this
does not have any actual impact, but it removes one direct dependency on
eventlet.
Change-Id: I0a4edf8e885c2311d1e8a7eb1fe5d79070f99649
Signed-off-by: Arnaud Morin <arnaud.morin@gmail.com>
Currently Mistal doesn`t support distribution tracing, which means
that there`s no way to propagate traceId/spanId from an execution to
related actions/notifications.
It leads us to an issue, because according to distribution tracing
principles "traceId" should remain the same during the discovery
process, which includes Mistral worflow execution.
Proposed solution is to keep some headers from execution request
and propagate them later to actions/notifications.
Regexp can be stored as env variable to define headers which
will be propagated.
Implements blueprint add-headers-propagation
Change-Id: Id8cc900a7d94286e79f1ece4dc4177383263f55c
* with_items_index describes the current index of action,
if there is no with-items tasks it should be 0.
* task_rerun_no describes the current rerun index,
if it is first run it should be 0.
* task_rerun_id specifies id task has within
each rerun. This id should be refreshed after each rerun.
All these fields will be helpful for writing custom actions
Change-Id: I2b76f5cedcac942e3b6a6e9488ae89024c4f1b34
Signed-off-by: Oleg Ovcharuk <vgvoleg@gmail.com>
* This patch adds the base infrastructure for the new concept
that we call Action Providers. It will allow to refactor
Mistral in a way that all action management will be encapsulated
with action providers. For example, Mistral Engine needs to
schedule actions while processing a workflow. Now it has to
access DB itself to find an action definition (meta info about
what this action is, like python class, input params etc.),
then prepare input parameters, validate parameters and send a
message to an executor to run it. In many other places, Mistral
also directly access DB to fetch an action definition. It's
not flexible because we assume that definitions of Mistral
actions must always be stored in DB. The concept of an Action
Provider allows moving away from that limitation. A particular
implementation of the ActionProvider interface can store action
definitions in any suitable way, even fetching them using
various transport protocols like AMQP, HTTP, TCP, or anything
else. An action provider may also generate action definitions
dynamically, like creating wrappers around a set of operating
system commands. But for the rest of the system it won't matter
what happens inside action providers. All details will be
hidden behind a unified interface.
* Added ActionDescriptor interface and its convenience base
abstract implementation. ActionDescriptor is an entity
representing an action before it's instantiated. It carries
the most important meta information about an action like name,
description, input parameters etc. It is also responsible for
validating action input parameters and instantiating a real
action.
* Added PythonActionDescriptor which represents a regular action
written as a Python class.
* Added CompositeActionProvider that delegates calls find() and
find_all() to a collection of other action providers.
* Minor style changes.
Partially implements: bp/mistral-action-providers
Change-Id: Ic9108c9293731b3576081c75f2786e1156ba0ccd
* These constants have nothing to do with this project. They should
be in the 'mistral' repo.
* Minor style changes.
Change-Id: Ia3f50388638d68bbcc5e2e9e424ddb9dd65b26eb
* This patch adds a utility that helps serialize data into a JSON
string that might contain some non-standard data types like
generators iterators and frozen dicts coming from YAQL. The
utility uses oslo.serialization project that already takes care
of iterators and any kinds of custom dicts. And in addition, it
handles generators (assuming a generator represents an iterable
similar to an iterator).
* Unit tests.
* Added YAQL into requirements and bumped the version of
oslo.serialization to make sure to have the "fallback" parameter
in "jsonutils.to_primitive"
Change-Id: I2fe891525bc86beb92aecf9ac2d8a490837c47d3
Mistral didn't make use of the oslo_utils "mask_password" methods,
leading in sensitive data leakage in its logs.
This patch corrects this security issue.
Note that it depends on oslo_utils patch adding new patterns, and
ensuring it's case-insensitive.
Change-Id: I544d3c172f2dea02c62c49c311c4b5954413ae15
Related-Bug: #1850843
Co-Authored-By: Dougal Matthews <dougal@redhat.com>
Signed-off-by: Cédric Jeanneret <cjeanner@redhat.com>
Currently if Mistral needs to pass the ActionContext via it's internal
rpc calls it wont be serialised. This change should have no end-user
impact, but makes it easier for Mistral to use internally.
Change-Id: I238355d52c77d622740527e43ddb2b7484cc58db
The previous attempt at this was to redirect as little as possible.
However, this has proven to be problematic twice. auth_cacert wasn't
redirected, it was used by some of the OpenStack actions and thus
blocked Mistral [1] patch that would have Mistral start using the new
context.
This change redirects all properties in the SecurityContext which should
be safer for our internal actions and for end users actions.
[1]: https://review.openstack.org/#/c/506185/14
Partial-Bug: #1718353
Needed-By: Ife653558bfcda794e7f37086832f70b0ad7c28a4
Change-Id: I6057d0ce3fe4ae23468be8fb06cb85dc5f467f6b
The previous name isn't consistent and it is confusing, tasks don't have
an ID, but the execution for a task does.
Related-Bug: #1718353
Change-Id: I049cf7312c58d83e9405aaa36a6961cca006cb16
In the recent parameter migration, a number of parameters were
incorrectly deprecated. They were not redirected to the new location
correctly and would cause an error.
Change-Id: I5ea09c3c79df5a43b06194a48f7425a15a1b23cf
Closes-Bug: #1728081
Without this, the action loading will fail in Python 2 if the action
subclass doesn't define a __init__.
Closes-Bug: #1724594
Change-Id: I7cf9fdc9446462c7f5010d0ba8b307b05656704e
This allows us to better define the expected interface and provide
additional context information to actions.
The existing context is deprecated with this change and will output
deprecation warnings for the old property names.
Change-Id: Ib879ba58d4b9a04d4f5ea668ae94d79a82758919
Partial-Bug: #1718353
Note: We need to switch to 'serialization' from 'mistral-lib' as soon
as we switch 'mistral' to use 'mistral-lib'.
Change-Id: I608ba7abb097d19cce3d20c48e1669fa4b96dc77
Action was added to mistral_lib.actions to make it simpler to use.
However, generally you also need the Result class. This adds it in the
same place, so actions developers only need to import one module to
access both classes.
Change-Id: I51ae3440ac62ebad5ae13a5e3edf01df66af71c7
This patch includes the initial data types, serialization,
string utilities, base exception classes and defines a
base action that includes a context argument.
The mistral_lib.api namespace was also removed in favor of
following the python convention of using an underscore to
denote private methods and considering all other methods
public.
This patch removes code previously added as a placeholder
to match the spec. As of the Atlanta PTG, the purpose of
this library is now to store common code used within Mistral
ecosystem and 3rd party integration interfaces including
the Custom Actions API and Custom YAQL Functions API.
Change-Id: I77da3cd6eba6c5a9953656d432bc959bd3747ada
Partially-Implements: blueprint mistral-custom-actions-api
Partially-Implements: blueprint mistral-actions-api-main-entities
This patch renames the mistral directory to mistral_lib to ensure
an action would not hit a namespace issue when attempting to import.
e.g. "from mistral import context".
Change-Id: I984b6a9569aef9e9f52fb3c037ff133081b7d933