* 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
* 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
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>
* 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
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
If we leave is_system workbook attribute as undefined (Null) that causes
database insert error in MySQL 5.7, due to database constraints.
So let's use constant False as is_system attribute in workbook create.
It is OK, because there is no system workbook support in mistral yet.
Change-Id: Idabf9d04d105c2386b9b110f1bbab3e69502b8e0
Closes-Bug: #1733501
Allow adding many workflows with the same name.
The way this works is by adding the new workflows under another
namespace.
Notice that:
1. Namespaces are not part of the mistral DSL.
2. When executing a workflow, the namespace passes down to the
subworkflow.
3. When searching for the sub-workflow definition -
If no workflow was found in the given namespace, than the defualt
namespace will be used.
4. The default namespace is an empty string.
5. The namespace property or the workflow execution will be under
params
Partially-Implements: blueprint create-and-run-workflows-within-a-namespace
Change-Id: Id248ec5906a0899d188675d002b45f6249d36d90
* The previous name of the package is not relevant anymore, it was
chosen for reasons that don't make sense anymore. A name of the
package should reflect that it's about the workflow language.
Change-Id: I7e05ba97abf0aa5db4e19d9d72b4ea0d52e328fb
* The problem was that cache instance was instantiated on different
Mistral instances and invalidation didn't work properly (known
problem for local cache implementations). The solution, first of
all, is to cache specifications by workflow execution ids so that
we get a consistent spec value during workflow execution lifetime.
And secondly, if we need to build a specification based on
workflow definition id we also need to use 'updated_at' as part of
cache key so that if workflow definition has changed the cache is
updated properly. Old cache entities would be kicked out of cache
by LRU algorithm as the cache runs out of space.
Change-Id: If97b2e47d8adcbd7b5d5844b56e24eac1b1ae6c1
While creating workbook, action definition was not saved to
database. Due to which user was unable to see action definition
Change-Id: I69cf129d17d8db735770fc6231062cd61b3d4156
Closes-Bug: #1504429
There's no need to use that function for the purpose of calculating
indentation.
This patch is supplementary to the previouse patch[1], which I have
wrongly pressed workflow+1 button to have it merged. Please see my
comments there.
Fix the wrong indentation of workflow definition as well.
[1]: https://review.openstack.org/#/c/225559/
Change-Id: I8daac2f81989cff83abcb01096bdf84eae5d89eb
While creating workbook, workflow definition was not saved to
database. Due to which user was unable to see workflow definition
Change-Id: I0e3518be17198eadcc57a2eb8f15dc25266d338a
Closes-Bug: #1493343
* new engine method (symmetrically to start_workflow) -
start_action;
* possibility to run action without saving the result
to the DB;
* adjusted model_base: updated_at indeed can be None
in set of cases;
* improved engine.utils.validate_input for checking
action_input (also adhoc action input); for this
new util method for getting input dict from input
string is introduced;
* executor client can call rpc method synchronously
for immediately returning result from action and
without callback to engine;
* fixed uploading actions from workbook;
* improved action_handler;
* improved inspect_utils for input validation needs.
TODO (next commit):
- Implementing run action API side
Partially implements blueprint mistral-run-individual-action
Change-Id: I2fc1f3bb4382b72d6de7d7508c82d64e64ca656c
* Created a Execution hierarcy mapped on a single table:
- ActionExecution
- WorkflowExecution
- TaskExecution
* Created necessary associations within Execution hierarchy
* Created necessary methods for Execution objects on DB API
* Created Definition hierarchy mapped on separate tables:
- Workbook
- WorkflowDefinition
- ActionDefinition
* Renamed attributes
- 'wf_name' -> 'workflow_name'
- 'wf_spec' -> 'spec'
* Fixed all unit tests
TODO:
* Complete renaming throughout the code
* Further refactoring of workflow engine
Change-Id: I0032bea573d9200025f9f7dd951e93cb6f1661bb
* Refactored DB models with new mixin class MistralSecureModelMixin
* Refactored services working with workflows, worbooks, actions
* Other minor changes
Change-Id: I9f2cb5c02670aa8c4c3dd06c4301f2e613f5c013
* Getting rid of dictionary as a parameter for create_workbook_v2() and
update_workbook_v2(), instead a plain string (yaml definition) is used
* Fixed all the calls of these methods
* Fixed unit tests
Change-Id: I70dcbf844e2d10ab6619de7972f0253022c534cd
* Added Workflow DB model
* Removed 'workbook_name' parameter from Engine.start_workflow signature
* Fixed unit tests
* Fixed module trusts to create individual workbook entities when
on workbook definition update
* Fixed API tests
* Switched v1 controllers to explicitly use DB API v1
Change-Id: I6a096e1c5d8082d3d1cdd47b575b85b28224d2a6
* "events" are renamed to "triggers"
* triggers moved out of workflow section
Implements: blueprint mistral-rename-event-to-trigger
Change-Id: I5b76e9c063a3ce9eec5d485bb5db5e22ac7981d4
* Moved pecan configuration to oslo config
* Refactored functional base test
* Got rig of thread local related code in mistral/context.py
* Added new exception ApplicationContextNotFoundException
* Fixed example configuration file
* Made minor cosmetic changes (blank lines, naming)
Change-Id: I1899ce2562a34ebafa20c5735bdf4f0c80dd0175
Renat Akhmerov